ESP32 Forum

Posted: **Tue Dec 01, 2015 1:01 pm**

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

Posted: **Fri Dec 04, 2015 9:39 am**

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

Posted: **Mon Dec 14, 2015 11:28 pm**

Sprite_tm wrote:esptool.py variant which can flash the ESP31

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

Posted: **Tue Dec 15, 2015 3:27 am**

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.

Posted: **Tue Dec 15, 2015 5:34 am**

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

Posted: **Tue Dec 15, 2015 6:07 am**

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

Posted: **Tue Dec 15, 2015 3:34 pm**

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

Posted: **Wed Dec 16, 2015 2:04 am**

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.

Posted: **Wed Dec 16, 2015 9:47 am**

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?

Posted: **Wed Dec 16, 2015 10:31 am**

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?

ESP32 Forum

Flash Tool

Flash Tool

Re: Flash Tool

Re: Flash Tool

Re: Flash Tool

Re: Flash Tool

Re: Flash Tool

Re: Flash Tool

Re: Flash Tool

Re: Flash Tool

Re: Flash Tool