MicroPython Forum (Archive)

According to the post, they do not seem to. But the Arduino, at least the older ones, have a very strange sharing between an USB/Serial converter and the ATMega controller. So the TX pin of the arduino is the RX of the USB/Serial converter. If the ATMega is practically not used in this setup, it could work, but it's surely a good candidate for trouble.
Update: Looks like it could work if the Arduino is kept in reset state, and then indeed RX ->RX and TX -> TX. But i do no know if it matches the speed.

When flashing bare ESP modules i tend to use one of my pyboards just as a 3v3 power supply (sharing GND across involved components of course). This does provide the >250mA peaks the ESP tend to draw in AP mode.

As a USB-serial adapter i do either use my lovely Buspirate (in UART mode as a transparent bridge; this is my favorite toy ) or my USB-BUB-II but any cheap china USB-TTL should do fine.

Just to clarify. I do have the arduino reset pin GND. I'm using the epstool to flash. I am just wondering if there is something on the CLI that I am not doing correctly.

This is the CLI I am using now.
esptool -pCOM6 -b115200 write_flash --flash_size 8m 0 esp8266-20160923-v1.8.4-59-g6d310a5.bin

This is a 1MB ESP01 so I set the flash size to 8m. Starting at 0x0. Does that sound correct?

Thanks!

Ok. Another interesting thing. I just flashed the latest daily firmware for the heck of it and I used a much higher baud rate (400000 vs 115200) based on RobertHH's post that higher baud rates should be used for flashing. The flash went MUCH faster as you can imagine. Then the output from the device started, but when I went to view it in miniterm it was all garbage control characters. Normally it says Fatal Exception over and over again. So I tried connecting again to the serial port with various baud rates to see if I could clean up the garbage. I used the flashing baud rate of 400000 and I started seeing the proper text again with the repeating Fatal Exception errors. Just another observation. Thanks.

One more observation. I did flash a sketch via the arduino to the ESP01. It scans wifi and reports the names of the access points it sees. So it looks like the board is functional from that aspect. Thanks.

Cannot tell. I use 'make deploy' for flashing, which issues the command:

esptool.py --port /dev/ttyUSB0 --baud 115200 write_flash --verify --flash_size=8m 0 build/firmware-combined.bin

Given that, your command looks right. After flashing, I have to reset the ESP, Otherwise I see garbage, and the commmuncation speed has to be 115200.

Update: I downloaded the latest build & ran:

esptool.py -p/dev/ttyUSB0 -b115200 write_flash --flash_size 8m 0 esp8266-20160923-v1.8.4-59-g6d310a5.bin

on a ESP-01 with 1 MByte of flash. Besides the port name, it's similar to yours. After reconnecting, with:

picocom -b 115200 /dev/ttyUSB0

it spit out some garbage, and then:

could not open file 'main.py' for reading

MicroPython v1.8.4-59-g6d310a5 on 2016-09-23; ESP module with ESP8266
Type "help()" for more information.
>>>

So far, it looks OK. Did you try to erase flash beforehand?

RobertHH - Thanks!

Yes. I have erased the flash each time, but I have not built the firmware from scratch. I was trying to avoid that, but perhaps I should give it a shot.

Roberthh wrote:Cannot tell. I use 'make deploy' for flashing, which issues the command:

esptool.py --port /dev/ttyUSB0 --baud 115200 write_flash --verify --flash_size=8m 0 build/firmware-combined.bin

Given that, your command looks right. After flashing, I have to reset the ESP, Otherwise I see garbage, and the commmuncation speed has to be 115200.

Update: I downloaded the latest build & ran:

esptool.py -p/dev/ttyUSB0 -b115200 write_flash --flash_size 8m 0 esp8266-20160923-v1.8.4-59-g6d310a5.bin

on a ESP-01 with 1 MByte of flash. Besides the port name, it's similar to yours. After reconnecting, with:

picocom -b 115200 /dev/ttyUSB0

it spit out some garbage, and then:

could not open file 'main.py' for reading

MicroPython v1.8.4-59-g6d310a5 on 2016-09-23; ESP module with ESP8266
Type "help()" for more information.
>>>

So far, it looks OK. Did you try to erase flash beforehand?

I do not expect that building the firmware from scratch makes a difference. The only differences to my test are:

- the OS
- the esptool version. Mine is "esptool.py v1.2-dev - ESP8266 ROM Bootloader Utility"

Could you try to use the verify option with esptool (--verify)?

c:\>esptool -pCOM6 -b115200 write_flash --flash_size 8m 0 esp8266-20160923-v1.8.4-59-g6d310a5.bin
esptool.py v1.1
Connecting...
Running Cesanta flasher stub...
Flash params set to 0x0020
Writing 532480 @ 0x0... 146432 (27 %)
A fatal error occurred: Invalid head of packet ('r')

Interestingly this time I got an Invalid head of packet.

I flashed again after erasing the firmware and it completed fine.

I saw this in the debugging.

ets Jan 8 2013,rst cause:2, boot mode:(1,6)

Is there a list of what these boot mode messages mean?

Thanks!

RobertHH,

It looks like the verify failed.

C:\>esptool -pCOM6 -b115200 write_flash --verify --flash_size 8m 0 esp8266-20160923-v1.8.4-59-g6d310a5.bin
esptool.py v1.1
Connecting...
Running Cesanta flasher stub...
Flash params set to 0x0020
Writing 532480 @ 0x0... 532480 (100 %)
Wrote 532480 bytes at 0x0 in 45.4 seconds (93.9 kbit/s)...
Leaving...
Verifying just-written flash...
Verifying 0x81650 (530000) bytes @ 0x00000000 in flash against esp8266-20160923-v1.8.4-59-g6d310a5.bin...
-- verify FAILED (digest mismatch)

A fatal error occurred: Verify failed.

Roberthh wrote:I do not expect that building the firmware from scratch makes a difference. The only differences to my test are:

- the OS
- the esptool version. Mine is "esptool.py v1.2-dev - ESP8266 ROM Bootloader Utility"

Could you try to use the verify option with esptool (--verify)?