Closed Trbe closed 1 year ago
Saved PC:0x40049a42 [chip726_phyrom_version_num:??:??]
This means it's hanging inside the ROM bootloader, the second stage bootloader (part of what is flashed to the board) isn't even running yet.
The fact when you cycle the power it starts working shows that everything is flashed correctly. Very strange :thinking:. What happens when you try and flash the board with esptool.py?
@MabezDev I don't really know how to do that.
But I tried esptool.py -c esp32c3 -p /dev/ttyCH343USB0 -b 921600 --before default_reset --after hard_reset write_flash -z --flash_mode dio --flash_freq 80m --flash_size 4MB 0x10000 target/riscv32imc-esp-espidf/debug/esp-hello
and get this
esptool.py v4.1
Serial port /dev/ttyCH343USB0
Connecting...
Failed to get PID of a device on /dev/ttyCH343USB0, using standard reset sequence.
.
Chip is ESP32-C3 (revision 3)
Features: Wi-Fi
Crystal is 40MHz
MAC: 60:55:f9:77:57:38
Uploading stub...
Running stub...
Stub running...
Changing baud rate to 921600
Changed.
Configuring flash size...
A fatal error occurred: File target/riscv32imc-esp-espidf/debug/esp-hello (length 15118644) at offset 65536 will not fit in 4194304 bytes of flash. Use --flash_size argument, or change flashing address.
I also tried esptool.py -c esp32c3 -p /dev/ttyCH343USB0 -b 921600 write_flash -z 0x10000 target/riscv32imc-esp-espidf/debug/esp-hello
and get
esptool.py v4.1
Serial port /dev/ttyCH343USB0
Connecting...
Failed to get PID of a device on /dev/ttyCH343USB0, using standard reset sequence.
.
Chip is ESP32-C3 (revision 3)
Features: Wi-Fi
Crystal is 40MHz
MAC: 60:55:f9:77:57:38
Uploading stub...
Running stub...
Stub running...
Changing baud rate to 921600
Changed.
Configuring flash size...
Flash will be erased from 0x00010000 to 0x00e78fff...
Compressed 15106792 bytes to 3662516...
Wrote 15106792 bytes (3662516 compressed) at 0x00010000 in 177.9 seconds (effective 679.2 kbit/s)...
File md5: 7f1368e9cfa8b525ff5e88b32169fdd3
Flash md5: 16f35777ec98e430e2ed62c14572ba90
MD5 of 0xFF is 0a2e10eeb2a5361078456398d41c84ec
A fatal error occurred: MD5 of file does not match data in flash!
And the monitor shows
...
invalid header: 0x00000000
invalid header: 0x00000000
invalid header: 0x00000000
invalid header: 0x00000000
invalid header: 0x00000000
invalid heade�ESP-ROM:esp32c3-api1-20210207
Build:Feb 7 2021
rst:0x7 (TG0WDT_SYS_RST),boot:0xf (SPI_FAST_FLASH_BOOT)
Saved PC:0x4004d1fa
invalid header: 0x00000000
invalid header: 0x00000000
invalid header: 0x00000000
invalid header: 0x00000000
invalid header: 0x00000000
invalid header: 0x00000000
invalid header: 0x00000000
invalid header: 0x00000000
invalid header: 0x00000000
invalid header: 0x00000000
invalid header: 0x00000000
invalid header: 0x00000000
invalid header: 0x00000000
invalid header: 0x00000000
invalid header: 0x00000000
invalid header: 0x00000000
invalid header: 0x00000000
...
I also test flash at 0x0, which gets the same result.
More over, I tested the example under .espressif/esp-idf/release-v4.4/examples/get-started
.
I use the idf.py to build and flash, and everything goes right.
Hey sorry this dropped off my radar, could you try again with the 1.6 release of espflash? Hopefully that fixes these strange issues!
Oops, new errors.
I encounter the issue as well, posting my logs
It's okay to
but with default configuration(I added the --flash-mode DIO
)
after comparison, I found that when ram stub is used(add --use-stub
), it works
So I found out that some flash chips soldered to dev boards (I believe some XMC chips) behave very strangely and the ROM bootloader may not know about this, which could be why it fails. The stub has workarounds for these chips so that should be used instead. Soon we will switch to using the stub by default but for now you should pass --use-stub
to espflash.
After I did
cargo espflash --monitor /dev/ttyCH343USB0
then I get thisloop in rst:0x7 and rst:0x10 While I re-plug the board, it boots normally.
It seems like the loading address is wrong.