bricking on rust sdk? (TZ-1157)

[lattice0]

Checklist

• Checked the issue tracker for similar issues to ensure this is not a duplicate
• Read the documentation to confirm the issue is not addressed there and your configuration is set correctly
• Tested with the latest version to ensure the issue hasn't been fixed

How often does this bug occurs?

always

I ask here because it only happens in this product even though this is for the C SDK. I'm sure it's not a defect on my board because it happened on both of my boards.

Expected behavior

flash all the time and use it

esp-rs/esp-hal#2212

Actual behavior (suspected bug)

does not prevent me from flashing the second time after first flash

Error logs or terminal output

No response

Steps to reproduce the behavior

buy brand new board
flash the esp32-h2 board with the latest rust sdk crate template (hello world project)
try to flash another program, it does not appear as a device on the list of devices on linux

Project release version

rust sdk (https://crates.io/crates/esp-hal)

System architecture

Intel/AMD 64-bit (modern PC, older Mac)

Operating system

Linux

Operating system version

ubuntu 22.04

Shell

Bash

Additional context

No response

[chshu]

@lattice0 Could you try the same on a standalone H2 devkit? The BR board includes additional logic where the S3 module can reset the H2 and put it into download mode, controlled by the firmware on the S3.

If you're developing the Thread BR feature on the BR board, there's no need to manually flash the H2 firmware. It can be updated automatically via the RCP update.

[lattice0]

@chshu indeed the standalone H2 devkit works fine, I've been using it.

Any explanations on why the H2 part of the BR board only starts resetting after the first flash? Also I'm not touching any C SDK stuff, I'm just playing with the board via rust, so I'm not using RCP.

Is there a way to fix this?

[chshu]

The firmware in S3 module will check the RCP version in H2 and compare to the firmware it stored locally, if they mismatch, S3 will trigger the RCP update process.

You can erase the S3 module on the BR board:

idf.py -p <S3_port> erase-flash

So it won't reset the H2 module anymore.

[lattice0]

I ran espflash /dev/ttyACM0 erase-flash on the S3 module, which was stable before as a linux usb device:

espflash erase-flash
[2024-09-23T02:11:06Z INFO ] Serial port: '/dev/ttyACM0'
[2024-09-23T02:11:06Z INFO ] Connecting...
[2024-09-23T02:11:06Z INFO ] Using flash stub
[2024-09-23T02:11:06Z INFO ] Erasing Flash...
[2024-09-23T02:11:13Z INFO ] Flash has been erased!

not I got an even stranger behaviour: the S3 also keeps resetting and appearing briefly as a device on linux, and the H2 continues with the same behaviour as well

[chshu]

Did you switch the USB port when perform the erase-flash? Please try the follow steps:

• connect the S3 USB port, perform the erase-flash
• disconnect the S3 USB port, and connect the H2 USB port
• flash your firmware, it will work as a standalone H2 devkit

Note that the default hello world example in esp-idf reboots every 10 seconds.

[lattice0]

@chshu yes I did switch and verify if carefully I ran erase-flash on the S3 for sure and now it's rebooting. None of the modules are on the default example anymore as well. And they are both rebooting very quickly now.

[chshu]

Rebooting is not an issue, S3 reboots since there is no working fimware, the ROM code keeps rebooting. H2 reboots may be caused by the fimware you have flashed. Could you share the output from both USB ports?

[lattice0]

@chshu when I say reboot I mean it appears birefly on lsusb and disappears so I cannot flash. Both of them do this now. Before the erase-flash it was just the H2, now the S3 does as well.

What do you mean about output from both usb ports?

Also the original program on the H2 was a hello world every half a second, from the template. I can't find it now.