Flash Tool

[rudi ;-)]

Hi espressif

can we use same flash tool like esp8266 or is there an extra flash tool?
can we download or how we will get this?

proposal: command line tool will be great, if we can run it in console by batch for multi flash.

best wishes
rudi

[ESP_Sprite]

If it's of any use, we have an esptool.py variant which can flash the ESP31. So yes, there is command line support.

[rojer9]

esptool.py variant which can flash the ESP31

where can i get it? can you share, please?

[ESP_Sprite]

Here you go. Please be aware that this is not an official Espressif tool and while this may change in the future, at the moment Espressif nor the original author support this version of esptool.py.

Ah, it also seems to have a small bug: on some configurations it won't succeed in putting the ESP31 in flash mode the first time. Just try again, the second time almost always succeeds.

[rudi ;-)]

Hi Jeroen

thanks! download just in time.
Jeroen, we have disadvantages if we one way or another to use before or that?
Is there a recommendation to use one?

best wishes
rudi

[ESP_Sprite]

To my knowledge, apart from the bug I mentioned, it should work just fine. I use it in my daily work, fwiw.

[rojer9]

Thanks!

i'm getting errors though. instead of failing occasionally, for me, it will occasionally work, but fail most of time.
i added some debug output and usually get this:

Code: Select all

Connecting...
connected on attempt 0
Erasing flash...
Erase size 1400 num_blocks 5 offset 0
(1431642119, '\x00\xa9')
Traceback (most recent call last):
  File "/root/bin/esptool32", line 603, in <module>
    esp.flash_begin(blocks*esp.ESP_FLASH_BLOCK, address)
  File "/root/bin/esptool32", line 231, in flash_begin
    raise Exception('Failed to enter Flash download mode')
Exception: Failed to enter Flash download mode

that 0xa9 is the problem, it expects 0 there. success looks like this:

Code: Select all

Connecting...
connected on attempt 0
Erasing flash...
Erase size 1400 num_blocks 5 offset 0
(538052359, '\x00\x00')
Wrote 5120 bytes at 0x00000000 in 0.6 seconds (74.2 kbit/s)...

Leaving...
Erase size 0 num_blocks 0 offset 0
(538052359, '\x00\x00')

pretty strange. does 0xa9 mean anything or is it garbage? does seem to always be a9 though.
"val" bytes vary on failures, but are always 538052359 on success.


update:
i'm flashing boot.bin from the SDK at address 0:

Code: Select all

esptool32 --port /dev/ttyUSB3 write_flash 0 fw_rojer/bin/boot.bin

(i called this new esptool.py esptool32).

the command it sends to bootloader is:

Code: Select all

'\xc0\x00\x02\x10\x00\x00\x00\x00\x00\x00\x14\x00\x00\x05\x00\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\xc0'

and the response it gets back is:

Code: Select all

'\xc0\x01\x02\x02\x00\x07\x12UU\x00\xa9\xc0'

the dword "\x07UU\x00" varies - sometimes i get "U" (0x55), " "(0x20) or 0x00, the rest of the response stays the same.


update2:

i have a second module, so i soldered and tried it. result is the same - can't flash reliably, flash_begin fails.
but in this module second byte in the response instead of 0xa9 alternates between 0xde and 0xfe

[rojer9]

ok, figured it out.
it's the same "first flash" bug, but the difference is that i was triggering it all the time because of my wiring.
described in detail, the bug is as follows:
first flash_begin after reset (toggling CHIP_PU / EN pin) will most likely fail. if it succeeds (rarely but happens), it will stumble along (not go smoothly, have hiccups). return codes are as i described above.
retrying just flash_begin is not enough - you can do it until you're blue in the face, it will still be failing.
however, if you do a sync after the failure, without reset, next flash_begin will succeed and go smoothly (no hiccups).

i hate repetitive manual labor (including pressing buttons), so i use DTR and RTS to put chip into flashing mode every time.
so, for me, every flashing is the first and thus, i was hitting this bug all the time. with the "sync after first flash and retry" it now works reliably:

Code: Select all

$ ~/cesanta/esptool32 --port /dev/ttyPL --baud 230400 write_flash 0x40000 bin/irom0_flash.bin                                                                                         
Connecting...
Erasing flash...
Erase size 3b000 num_blocks ec offset 40000
FLASH_BEGIN failed, applying ESP32 workaround...
Wrote 241664 bytes at 0x00040000 in 14.3 seconds (134.8 kbit/s)...

i'm attaching updated esptool.py.

[bienvenu]

I'm not sure if this is a hardware/soldering issue or not, but I've never received a response to any message from esptool-esp31.

My module boots normally to the demo app. If I short GPIO0 to GND I get flash download mode, which spits this out of U0TXD:

Code: Select all

 ets Jul  5 2015,rst cause:1, boot mode:(13)

. _stack_sentry: 0x3fffe1d0, . __stack: 0x40000000, 
 . _bss_start: 0x3fffcd48, . _bss_end: 0x3fffe1d0, 
 . _data_start: 0x3fffc000, . _data_end: 0x3fffc864 

However, no amount of tinkering with esptool-esp31 or esptool32 gets a response from the ESP32. I've attached a screenshot showing see the module booting and my FTDI cable pushing bytes several times without response. My command was:

Code: Select all

./esptool32.py --port /dev/tty.usbserial-FTH159YK read_mac

Any thoughts? Am I not poking enough GPIO lines - not in the right mode?

[rojer9]

i can confirm that GPIO0 to GND is all you need. withthe console output you posted, it looks like you get into bootloader fine.
can you post the error you get?