search

espressif / esp-thread-br

Espressif Thread Border Router SDK
Apache License 2.0
114 stars 25 forks source link

bricking on rust sdk? (TZ-1157) #99

Open lattice0 opened 2 months ago

lattice0 commented 2 months ago

Checklist

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

https://github.com/esp-rs/esp-hal/issues/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 commented 2 months ago

@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 commented 2 months ago

@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 commented 2 months ago

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 commented 2 months ago

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 commented 2 months ago

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

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

lattice0 commented 2 months ago

@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 commented 2 months ago

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 commented 2 months ago

@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.