esp32s3 fails chip_id, erase_flash, etc (ESPTOOL-565) #808
Comments
github-actions
bot
changed the title
|
Hi @bamason2,
Are these all the same revision Also, can you please try older versions of esptool? Maybe we can try to pinpoint the commit that introduced a regression (if there is one). Thanks! |
|
We got the same issue on 1 of 70 tried custom boards (all revision v0.1). On this single one failing board the problem is consistent, i.e. happens all the time. The flash is empty and has never been programmed. I still think it has something to do with the part that increases the clock frequency, since a few rearrangements of the code there leads to the same issue, but only when the code that is increasing cpu frequency is present. Same code but setting it to 160 MHz instead of 240 MHz does not lead to the issue. Maybe there are some precautions that need to be taken when increasing the clock speed, such as doing it in a particular order or something? Adding delays in form of a Or maybe the particular ESP32-S3 module is simply broken on this unit? In any case, it would be good if @bamason2 could test the two mentioned commits above. @radimkarnis if you want the board that's failing we could send it to you. |
|
I'm getting the same issue with an UnexpectedMaker TinyS3. I bought a ProS3 at the same time and this works fine. OS: MacOS Mojave: 10.14.6 (18G9216) Problem: If I run the command: The output is: I'm going to try a few things tonight and see if I can come up with anything, but I'm pretty unfamiliar with native ESP stuff. |
|
Just an update: I've just tried esptool v4.3 and it worked flawlessly. I'm still curious as to why it doesn't work with v4.4 but also why this only affects the tinyS3 and not the proS3 module. Although it sounds like Emill above encountered the issue with 1 part out of a bunch...so perhaps it's just some variance in the hardware itself? I might apply some of the changes between 4.3 and 4.4 and see if I can help find what might be causing it... |
|
@Emill @fennecbutt thanks for the feedback. It seems like when the CPU frequency gets increased for faster transfer speeds, the variance in the hardware comes into play. Maybe little differences between the crystals on the devkits, I am not sure. @fennecbutt you could try running esptool on b25606b, this is one commit before the CPU speed increase was introduced. |
|
This commit dccf4df seems to cause the issue, previous one works fine but from this one and onwards it gets stuck at Running stub. Using an esp32-s3 as well. |
|
Update: I have been able to reproduce this issue on a windows 10 machine (v4.3 works, v4.4 doesn't), but if I try the same thing on a Mac, everything works. So the issue is both devkit AND host machine dependent. |
|
Hello @stefanounick @fennecbutt @Emill @bamason2, We don't want to revert this feature entirely and there are reports that slowing down the CPU helps. I would be grateful if you could help me test this. Thank you! |
|
Yes that branch works on my otherwise failing board, just as in my experiments as explained above, i.e. the workaround to set the frequency to 160 MHz instead of 240 MHz. I would like to know the cause though why 240 MHz does not work. I don't see any requirements in the reference manual about a sequence or similar how to safely change the frequency. I don't want to end up in the situation where a board can be programmed at 160 MHz but running the esp-idf application later at 240 MHz fails (for the same reason as we are investigating here). |
|
@radimkarnis sorry for the delay, holidays and all that. I've tested your branch; it works perfect every time. I've also been rebuilding the stub in that branch locally and SYSTEM_CPUPERIOD_MAX=2 always encounters the issue, SYSTEM_CPUPERIOD_MAX=1 never does. The weird thing I've discovered is that on one board, it works perfect every time (pro s3 as mentioned). On other board (tinys3) when cpu is set to 240Mhz, it will sometimes work. Hold down boot button and connect to usb, it won't work immediately but after leaving it some time it will work once, then fail. Or it will fail and then randomly work once before failing again. It seems I can consistently get it to work if I have left it for a certain duration. --- 30 minutes later --- So I've discovered that if I put the board in the freezer (or fridge) for a minute or two (not long at all), then it consistently works perfectly fine! Once it warms up again after a short while it stops working, I did this several times and on one held my thumb over the esp chip itself to warm it up faster, and it starting failing again after a shorter time. Very interesting and also frustrating. Not sure if it's bc the esp can't do 240MHz at room temp (which is low atm, it's Winter) or if it's a bad solder joint or something causing it that gets compressed when the board has been briefly chilled. FYI the tinys3 that has this issue has esp: The pros3 that does not have the issue has esp: |
|
@Emill @fennecbutt thanks for your thorough tests and verification! Although the reason is still unknown, I think we can now confirm that lowering the CPU freq to 160MHz is the solution. Fortunately, the benefits of faster transfer speeds are still here. In my tests, switching from 80MHz -> 160MHz nearly doubles the speeds, but 160MHZ -> 240MHz does not make any more significant difference. ESP32-S3 is the only chip in our lineup so far that supports 240MHz and USB-JTAG/Serial. I guess this is the only configuration having issues, we had no other reports.
I believe this only confirms the idea that this has something to do with the hardware. Unfortunately, I don't have the time to investigate about the possible implications for IDF apps. The goal here is to get rid of the regression in esptool. |
|
@radimkarnis and thank you for your attention on this issue, I understand you have a lot of things to do & this is just one thing on the list; such is tech! I've found a fix! (Let me know if you want me to throw together a PR) But root cause still unknown. In static void set_max_cpu_freq()
{
if (can_use_max_cpu_freq())
{
/* Set CPU frequency to max. This also increases SPI speed. */
#if ESP32C6
pcr_sysclk_conf_reg = READ_REG(PCR_SYSCLK_CONF_REG);
WRITE_REG(PCR_SYSCLK_CONF_REG, (pcr_sysclk_conf_reg & ~PCR_SOC_CLK_SEL_M) | (PCR_SOC_CLK_MAX << PCR_SOC_CLK_SEL_S));
#else
cpu_per_conf_reg = READ_REG(SYSTEM_CPU_PER_CONF_REG);
sysclk_conf_reg = READ_REG(SYSTEM_SYSCLK_CONF_REG);
WRITE_REG(SYSTEM_SYSCLK_CONF_REG, (sysclk_conf_reg & ~SYSTEM_SOC_CLK_SEL_M) | (SYSTEM_SOC_CLK_MAX << SYSTEM_SOC_CLK_SEL_S));
ets_delay_us(100);
WRITE_REG(SYSTEM_CPU_PER_CONF_REG, (cpu_per_conf_reg & ~SYSTEM_CPUPERIOD_SEL_M) | (SYSTEM_CPUPERIOD_MAX << SYSTEM_CPUPERIOD_SEL_S));
#endif
}
}
With this change I was able to leave I'm not sure if I'll spend more time looking into this either; the fix above works for me at 240MHz. My current theory is APB going from 320MHz to 480MHz on some chips take some time to settle or some other funky physics related thing, but now I should actually start the project I was intending to build with this board, ha ha. |
|
@fennecbutt this is great! thanks for looking into it and being persistent. We could try and consider this solution if we get more than one report that this helps. Unfortunately, I am not able to reproduce this issue in my environment. Maybe we could ask @Emill to help.
Good luck with that, hopefully no other weird issue pops up to slow you down. |
|
I can confirm that @fennecbutt 's changes fix the issue here as well. |
|
@stefanounick thanks a lot for the confirmation! I will merge @fennecbutt's solution ASAP. |
|
I had the same problem with my UnexpectedMaker FeatherS3 board. Unfortunately esptool 4.5.dev2 does not seem to fix it for me. However, 4.3 worked correctly. Attached traces for both if it helps. |
1 task
dobairoland
pushed a commit
to espressif/esptool-legacy-flasher-stub
that referenced
this issue
May 30, 2024
Closes espressif/esptool#808 Thanks to @fennecbutt, @Emill, and @stefanounick for the implementation and testing
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Operating System
macOs 13.0.1
Esptool Version
Esptool 4.4
Python Version
Python 3.9.15
Chip Description
esp32-s3
Device Description
Adafruit feather esp32-s3
Hardware Configuration
No response
How is Esptool Run
Terminal
Full Esptool Command Line that Was Run
esptool.py --port /dev/tty.usbmodem101 --baud 115200 --chip esp32s3 chip_id
Esptool Output
More Information
Esptool runs but stops on 'running stub' indefinitely. Device is in boot mode. Have tried various options: --before no_reset_no_sync, no_reset --after no reset. Tried various larger values of MEM_END_ROM_TIMEOUT up to 2.5. I don't think it is a comms problem since the Web Serial JS tool works fine (https://github.com/makermelissa/Adafruit_WebSerial_ESPTool), can enter REPL using rshell, etc. Also running the --no_stub option works fine but unable then to erase_flash.
Tried on multiple esp32-s3 all have same problem. Esptool works fine on same setup with ESP32-D0WD-V3 and others with usb to serial (SIL 2104, etc).
Other Steps to Reproduce
No response
I Have Read the Troubleshooting Guide
The text was updated successfully, but these errors were encountered: