ESP32: Stub sends (occasionally) something else instead of the greeting message

[dobairoland]

I'm using the following command in all of my experiments.

esptool.py --port /dev/ttyUSB0 chip_id

and ESP32-D0WD (revision v0.0).

If I use the stub from the latest release (v0.2.0) then everything works fine.

If I use a stub manually built based on 09944f9 or 6c5c0f4 then the command works only rarely. I'm sorry but I'm not able to build older revisions to pinpoint which commit introduced the issue because I'm getting various build errors for commits older than mentioned.

The reason of the failure is that when the stub is running then it should send c0+OHAI+c0 in the beginning. This is done correctly only 1 or 2 times out of 5 attempts. In the rest of the cases either d0014081 or f0216081 is received. I have no idea what these could be as their are not sent as part of a proper SLIP package.

[dobairoland]

@SergioGasquez Could you please take a look?

[MabezDev]

It could be #50, @dobairoland if you add this line: https://github.com/esp-rs/esp-flasher-stub/pull/50/files#diff-d8c31d407e43532e4152070bdaf92d7fff58c81b39b4308cad7c769519d31376L451 back, and rebuild the stub does it work correctly?

[dobairoland]

Thank you for checking this issue. Unfortunately, the following change didn't help and I experience the same issue.

diff --git a/src/protocol.rs b/src/protocol.rs
index dc772ac..af11856 100644
--- a/src/protocol.rs
+++ b/src/protocol.rs
@@ -448,7 +448,7 @@ impl<T: InputIO> Stub<T> {
                 self.send_response(response);
                 self.target.delay_us(15_000); // Wait for response to be transfered
                 self.target.change_baudrate(baud.old, baud.new);
-                self.target.delay_us(1_000);
+                self.send_greeting();
                 response_sent = true;
             }
             EraseFlash => self.target.erase_flash()?,

[SergioGasquez]

@dobairoland Maybe try with all the changes of that PR or just bisect it. I guess it should be #50, #57 or #48, there shouldn't be many more options.

[dobairoland]

I narrowed down the issue.

9f1e566 - works perfectly fine for me. (built by me)

If I apply the following changes from the next merge then it breaks it:

diff --git a/Cargo.toml b/Cargo.toml
index bbb8223..b0c9698 100644
--- a/Cargo.toml
+++ b/Cargo.toml
@@ -8,13 +8,7 @@ categories   = ["embedded", "no-std"]

 [dependencies]
 critical-section = "1.1.2"
-esp32-hal        = { version = "0.17.0", optional = true }
-esp32c2-hal      = { version = "0.12.0", optional = true }
-esp32c3-hal      = { version = "0.14.0", optional = true }
-esp32c6-hal      = { version = "0.7.0",  optional = true }
-esp32h2-hal      = { version = "0.5.0",  optional = true }
-esp32s2-hal      = { version = "0.14.0", optional = true }
-esp32s3-hal      = { version = "0.14.0", optional = true }
+esp-hal = { version = "0.16.0" }
 heapless         = { version = "0.8.0",  default-features = false }
 static_cell      = "2.0.0"

@@ -25,13 +19,13 @@ mockall        = "0.12.1"
 mockall_double = "0.3.1"

 [features]
-esp32   = ["esp32-hal"]
-esp32c2 = ["esp32c2-hal"]
-esp32c3 = ["esp32c3-hal"]
-esp32c6 = ["esp32c6-hal"]
-esp32h2 = ["esp32h2-hal"]
-esp32s2 = ["esp32s2-hal"]
-esp32s3 = ["esp32s3-hal"]
+esp32   = ["esp-hal/esp32"]
+esp32c2 = ["esp-hal/esp32c2"]
+esp32c3 = ["esp-hal/esp32c3"]
+esp32c6 = ["esp-hal/esp32c6"]
+esp32h2 = ["esp-hal/esp32h2"]
+esp32s2 = ["esp-hal/esp32s2"]
+esp32s3 = ["esp-hal/esp32s3"]
 dprint  = []

 [profile.release]
diff --git a/src/lib.rs b/src/lib.rs
index 3687134..4ebcba9 100644
--- a/src/lib.rs
+++ b/src/lib.rs
@@ -23,23 +23,7 @@ pub mod miniz_types;
 pub mod protocol;
 pub mod targets;

-// Re-export the correct HAL based on which feature is active
-pub mod hal {
-    #[cfg(feature = "esp32")]
-    pub use esp32_hal::*;
-    #[cfg(feature = "esp32c2")]
-    pub use esp32c2_hal::*;
-    #[cfg(feature = "esp32c3")]
-    pub use esp32c3_hal::*;
-    #[cfg(feature = "esp32c6")]
-    pub use esp32c6_hal::*;
-    #[cfg(feature = "esp32h2")]
-    pub use esp32h2_hal::*;
-    #[cfg(feature = "esp32s2")]
-    pub use esp32s2_hal::*;
-    #[cfg(feature = "esp32s3")]
-    pub use esp32s3_hal::*;
-}
+pub use esp_hal as hal;

 use self::{

I tried to apply before this experiment other (more suspicious) changes from e9b6129 but I wasn't able to break the stub with those.

[dobairoland]

I'm getting this issue with the latest v0.3.0 release as well (with the binary from the release). It happens with 50% probability (5 times out of 10).

[SergioGasquez]

Are you able to reproduce this issue with other targets?

[dobairoland]

@SergioGasquez This might be an ESP32 only issue. I've just tried it with ESP32-S2 and ESP32-C6. I can reproduce it only with ESP32s (s means plural here).