Flashing troubles [SOLVED]

Hi, I'm trying to flash a ESP 32 board (precisely a ESP32D0WDQ6 revision 1) with no success.

I'm able to flash the device with Arduino IDE, the device boot and code works perfectly.

Then I've downloaded the Espruino late release and following the instruction I obtain the continuous boot loop.

E (62) boot: Chip CPU frequency rated for 160MHz. Modify CPU frequency in menuconfig
user code done
ets Jun 8 2016 00:22:57
rst:0x10 (RTCWDT_RTC_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0018,len:4
load:0x3fff001c,len:2668
load:0x40078000,len:7304
load:0x40080000,len:5312
entry 0x40080274

the strange fact is that if I flash the device using Adruino IDE then flash only the espruino bin the device boots.

Unfortunately it still reboot with this message:

E (62) boot: Chip CPU frequency rated for 160MHz. Modify CPU frequency in menuconfig user code done ets Jun 8 2016 00:22:57 rst:0x10 (RTCWDT_RTC_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT) configsip: 0, SPIWP:0xee clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00 mode:DIO, clock div:2 load:0x3fff0018,len:4 load:0x3fff001c,len:2668 load:0x40078000,len:7304 load:0x40080000,len:5312 entry 0x40080274

Any idea?

What command did you use to flash Espruino?
Did you erase flash before flashing Espruino?
Did you flash all parts?

For example the last couple of times I used this command (basically what's in the ESP32 directory, replace COM6 with your com port):

esptool.py --port COM6 --baud 921600 write_flash -z --flash_mode "dio" --flash_freq "40m" 0x1000 bootloader.bin 0x10000 espruino_esp32.bin 0x8000 partitions_espruino.bin

I've copied your command replacing only the COM port. This is the output:

esptool.py --port COM4 --baud 921600 write_flash -z --flash_mode "dio" --flash_freq "40m" 0x1000 bootloader.bin 0x10000 espruino_esp32.bin 0x8000 partitions_espruino.bin
esptool.py v2.8
Serial port COM4
Connecting........___
Detecting chip type... ESP32
Chip is ESP32D0WDQ6 (revision 1)
Features: WiFi, BT, Dual Core, 160MHz, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
MAC: 84:0d:8e:11:2f:94
Uploading stub...
Running stub...
Stub running...
Changing baud rate to 921600
Changed.
Configuring flash size...
Auto-detected Flash size: 4MB
Compressed 15392 bytes to 10130...
Wrote 15392 bytes (10130 compressed) at 0x00001000 in 0.1 seconds (effective 985.4 kbit/s)...
Hash of data verified.
Compressed 1377824 bytes to 891085...
Wrote 1377824 bytes (891085 compressed) at 0x00010000 in 21.6 seconds (effective 511.3 kbit/s)...
Hash of data verified.
Compressed 3072 bytes to 166...
Wrote 3072 bytes (166 compressed) at 0x00008000 in 0.0 seconds (effective 2052.3 kbit/s)...
Hash of data verified.

Then using the web IDE I get the result captured in the attached image

1 Attachment

Thanks for the replay. I've answered in the next message.

I would omit (delete) --flash_mode "dio" --flash_freq "40m" from flashing command and lower the baud rate to 115200

I've followed your suggestion, but I get the same result:

C:\esptool\espruino_2v05.15_esp32> espruino_2v05.15_esp32>esptool.py --chip esp32 --port COM4 erase_flash
esptool.py v2.8
Serial port COM4
Connecting........__
Chip is ESP32D0WDQ6 (revision 1)
Features: WiFi, BT, Dual Core, 160MHz, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
MAC: 84:0d:8e:11:2f:94
Uploading stub...
Running stub...
Stub running...
Erasing flash (this may take a while)...
Chip erase completed successfully in 6.8s
Hard resetting via RTS pin...

C:\esptool\espruino_2v05.15_esp32>esptool.py --port COM4 --baud 921600 write_flash -z 0x1000 bootloader.bin 0x10000 espruino_esp32.bin 0x8000 partitions_espruino.bin
esptool.py v2.8
Serial port COM4
Connecting........__
Detecting chip type... ESP32
Chip is ESP32D0WDQ6 (revision 1)
Features: WiFi, BT, Dual Core, 160MHz, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
MAC: 84:0d:8e:11:2f:94
Uploading stub...
Running stub...
Stub running...
Changing baud rate to 921600
Changed.
Configuring flash size...
Auto-detected Flash size: 4MB
Compressed 15392 bytes to 10130...
Wrote 15392 bytes (10130 compressed) at 0x00001000 in 0.1 seconds (effective 954.7 kbit/s)...
Hash of data verified.
Compressed 1377824 bytes to 891085...
Wrote 1377824 bytes (891085 compressed) at 0x00010000 in 11.8 seconds (effective 938.0 kbit/s)...
Hash of data verified.
Compressed 3072 bytes to 166...
Wrote 3072 bytes (166 compressed) at 0x00008000 in 0.0 seconds (effective 1893.8 kbit/s)...
Hash of data verified.

Leaving...
Hard resetting via RTS pin...

C:\esptool\espruino_2v05.15_esp32>

IDE output is identical to the previously uploaded.

The fact that flashing with the Arduino IDE and then replacing the bin, the Espruino code boot and work for some seconds before to crash, make me think that the bootloader provided in the Espruino kit is bugged.

I've tried some old version with no luck. Can someone share the working kit version?
Thanks.

your baud rate is still 921600. Lower it to 115200
If that will not help you, then i'll try to flash my own ESP32 with most recent stable version and share result with you

i have found your error: wrong adresses on chip
Your:
write_flash -z 0x1000 bootloader.bin 0x10000 espruino_esp32.bin 0x8000 partitions_espruino.bin

Should be:
write_flash -z 0x1000 bootloader.bin 0x8000 partitions_espruino.bin 0x10000 espruino_esp32.bin

https://www.espruino.com/binaries/espruino_2v05_esp32/

C:\Users\lixas\Workspace\JS\ESP32_Firmware\2v05>esptool.py --chip esp32 --port COM3 --baud 115200 erase_flash
esptool.py v2.8
Serial port COM3
Connecting.....
Chip is ESP32D0WDQ6 (revision 1)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
MAC: 24:6f:28:0b:87:90
Uploading stub...
Running stub...
Stub running...
Erasing flash (this may take a while)...
Chip erase completed successfully in 8.5s
Hard resetting via RTS pin...

C:\Users\lixas\Workspace\JS\ESP32_Firmware\2v05>esptool.py --chip esp32 --port COM3 --baud 115200 write_flash -z 0x1000 bootloader.bin 0x8000 partitions_espruino.bin 0x10000 espruino_esp32.bin
esptool.py v2.8
Serial port COM3
Connecting......
Chip is ESP32D0WDQ6 (revision 1)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
MAC: 24:6f:28:0b:87:90
Uploading stub...
Running stub...
Stub running...
Configuring flash size...
Auto-detected Flash size: 4MB
Compressed 15392 bytes to 10130...
Wrote 15392 bytes (10130 compressed) at 0x00001000 in 0.9 seconds (effective 135.9 kbit/s)...
Hash of data verified.
Compressed 3072 bytes to 166...
Wrote 3072 bytes (166 compressed) at 0x00008000 in 0.0 seconds (effective 773.5 kbit/s)...
Hash of data verified.
Compressed 1377808 bytes to 891091...
Wrote 1377808 bytes (891091 compressed) at 0x00010000 in 79.6 seconds (effective 138.4 kbit/s)...
Hash of data verified.

Leaving...
Hard resetting via RTS pin...

IMPORTANT: change baud speed at IDE-> Settings-> Communication t0 115200

1 Attachment

Thanks Lixas, but unfortunately I did not receive the same result.

I've tried with lower speed. Tried with different cables and changed the pc's USB port

I got always the same boot loop as reported in my upload.

May be my board is not a standard one? I've attached a picture.

1 Attachment

Mine looks the same. Try to burn Micropython firmware just to be sure. Probably it has something to do with your particular board...

1 Attachment

Update: flashed again with Arduino IDE, then with esptool without erasing (only espruino.bin and partitions)

attached the result. It's clear that it work (I've don sum) then it crash for some reason.

1 Attachment

This will not help, but at least explain restarting. I see reason is RTCWDT_RTC_RESET - that means somewhere in begining watchdog is set up and board was reset by watchdog. I'm not aware of ways to disable a WDT if it was set up (based on expierence from micropython). In micropython, only way to keep your board running is to WDT.feed() the dog if that was set somewhere.

I guess the error comes from the Arduino bootload config/build. But in any case I was not looking to run the Espruino in this way. This is only to show that the bin flashing process works and so there must be a bug in the Espruino bootloader.bin

Otherwise I can't understand why with the Arduino boot loader, Espruino boots correctly.

there must be a bug in the Espruino bootloader.bin

I have various ESP32's and all works correctly (version 2v04 as i was testing what to choose- espruino or micropython). So you should try another esp32 if its available.

UPDATE: installing a very old kit (1.96 release) ESP boot properly.

Installing then the bin of a newer release do not help.

So I can confirm the the newer version of the bootloader contain some incompatibility at least with my board.

I'll try to find the last working kit to help the devs to find the bug.

I confirm that the last working version is the espruino_2v00_esp32

Upgrading only the espruino_esp32.bin do not help.

So after the 2.00 a compatibility limit has been introduced. I hope my research can help in finding the bug.

I have used later versions without problem. Right now I have 2v04.406 on two ESP32 boards (one TTGO T-display, one generic).

One thing could be the power supply: Espruino turns on the wifi radio right at boot and both cores at full power without sleep. Significantly higher power draw, and that may cause a brownout with Espruino with the same power supply & cable that works with Arduino or Micro Python. Since (AFAIK) those don't turn on the radio at boot by default.

Can you try a shorter / better USB cable and adding some extra decoupling capacitor on the board?

Thanks AkosLukacs.

I've tried with many different cables including a very short one (14 cm) without success.

In addition I've tried all the releases since the 1.96 up to the last and every old release older than the 2.00 work fine. Therefore I do not think the issue is caused by random element like a cable quality o board specific configuration.

More probably from the 2.1 on the bootloader or the main image contains some code that can cause the issue systematically. It is clear that there must be a specific reason on my board, but it was there since the the earlier version.

SOLVED:

I've opened an issue on githup: https://github.com/espruino/Espruino/issues/1804

From version 2.01 on the board running with 160 MHz clock are no more supported by Espruino, and this is the case of my board.