Closed AnthonyGrondin closed 5 months ago
Hi! Thanks for reporting this issue. I just did a quick try and I was able to reproduce it. It looks like a stub issue as using --no-stub
solves the issue. Here are the debug logs using the stub:
[2024-02-27T20:25:44Z WARN ] Setting baud rate higher than 115,200 can cause issues
[2024-02-27T20:25:44Z DEBUG] Change baud to: 921600
[2024-02-27T20:25:44Z DEBUG] Writing command: ChangeBaudrate { new_baud: 921600, prior_baud: 115384 }
Error: espflash::timeout
× Error while connecting to device
╰─▶ Timeout while running ChangeBaudrate command
The prio_baud
looks a bit weird to me.
When trying the same command for an ESP32-C3, the command succeeds:
❯ espflash flash --baud 921600 --monitor target/riscv32imc-unknown-none-elf/debug/esp32c3
[2024-02-27T20:30:54Z INFO ] Serial port: '/dev/ttyACM0'
[2024-02-27T20:30:54Z INFO ] Connecting...
[2024-02-27T20:30:54Z INFO ] Using flash stub
[2024-02-27T20:30:54Z WARN ] Setting baud rate higher than 115,200 can cause issues
Chip type: esp32c3 (revision v0.3)
Crystal frequency: 40 MHz
Flash size: 4MB
Features: WiFi, BLE
MAC address: 60:55:f9:c0:39:7c
App/part. size: 223,248/4,128,768 bytes, 5.41%
[2024-02-27T20:30:54Z INFO ] Segment at address '0x0' has not changed, skipping write
[2024-02-27T20:30:54Z INFO ] Segment at address '0x8000' has not changed, skipping write
[2024-02-27T20:30:54Z INFO ] Segment at address '0x10000' has not changed, skipping write
[2024-02-27T20:30:55Z INFO ] Flashing has completed!
A bit more of information, I've regenerated the S3 stub with current main
of esp-flasher-stub
, enabling dprint
s and the stubs receives the change baud command:
process command: ChangeBaudrate
Waiting for command
So, either we are not processing the ChangeBaudrate
command properly in the stub or espflash
is not reading the OHAI response properly
I will be on vacations for the rest of the week! Will take a look at it as soon as I come back!
Moved this issue from espflash
repo. Using espflash 3.0.0-rc.1
with --no-stub
or the C stub works fine.
I've tried regenerating the S3 stub:
main
(rev 3b6a3cf3a4215889f803e3c1b9e684e2248e2db5
) with the following changes:
diff --git a/esp-hal/src/uart.rs b/esp-hal/src/uart.rs
index 08bd24c..ba32845 100644
--- a/esp-hal/src/uart.rs
+++ b/esp-hal/src/uart.rs
@@ -799,13 +799,13 @@ where
fn change_baud(&self, baudrate: u32, clocks: &Clocks) {
// we force the clock source to be APB and don't use the decimal part of the
// divider
let clk = clocks.xtal_clock.to_Hz(); let max_div = 0b1111_1111_1111 - 1; let clk_div = ((clk) + (max_div baudrate) - 1) / (max_div baudrate);
T::register_block().clk_conf().write(|w| unsafe { w.sclk_sel()
esp-flasher-stub
I just pointed to that esp-hal
repo using esp-hal-upgrade
branch changes.UART0_CLKDIV_REV
in get_uart_div()
Not sure if we should send_greeting()
in the ChangeBaudrate
processing.
ESP_SET_BAUD
in the C stub, it does not send the OHAI
messageC3 works fine:
espflash
of the ChangeBaudrate command results in:
[2024-03-04T14:54:29Z WARN ] Setting baud rate higher than 115,200 can cause issues
...
CommandResponse { resp: 1, return_op: 15, return_length: 2, value: ValueU32(0), error: 0, status: 0 }
Important update: Seems like the issue does not affect all the S3 targets. Some folks are able to flash different S3 devkits while changing the baudrate. Even the same devkit (ESP32-S3-DevKitC-1 v1.0
) works for some people and does not work for others.
I've also tested using different wires/computers and the results, for me, are the same, ESP32-S3-DevKitC-1 v1.0 does not work
Hi @AnthonyGrondin, I think I found the issue, could you try the following branch and see if it solves the issue for you?
cargo install espflash --git https://github.com/SergioGasquez/espflash --branch fix/s3-stub --force
I've tried with the updated espflash origin/main
and it fixes the issue. Thanks for taking care of this.
I'm running the same flash command, with
--baud 921600
, and it used to work previously, (IE in v2.1.0) but it is now returning a timeout error.With v2.1.0 (expected result):
With v3.0.0-rc.1 (bug: timeout):