‘Invalid head of packet’ error using ESPtool

[Mr.B]

I purchased 10 Oaks from the Kickstarter campaign.
After they arrived, I waited patiently until the official release of the firmware v1.

Today I have followed the Getting Started instructions.
I have had no success.
OTA appears to enter the ‘fast flash’ download stage and then stops after about 15 seconds.
Using the next suggested method – “oakupsrv”, resulted in my smartphone not being able to find the url presented by oakupsrv on my PC. The response from Chrome was “ERR_ADDRESS_UNREACHABLE”.

I have filtered down through all the trouble shooting and ended up at the instructions to flash the device over serial.

I have considerable electronics experience, so connecting the device up a 3.3V FTDI adaptor was no problem.
After reading some details on this forum, and considering the issues I had thus far, I decided it was best to flash oaksetup_restore.bin before I tried to flash firmware_v1.bin.

Using the following syntax:

Code: [Select]

esptool --baud 115200 --port COM5 write_flash -fs 32m 0x1000 blank.bin 0x2000 oaksetup_restore.bin 0x0081000 oakupdate_restore.bin 0x101000 blank.bin 0x102000 blank.bin 0x202000 blank.bin
I get ‘Invalid head of packet’ as can be seen below.
This is the result of multiple attempts. The process stops at a random percentage through.
I did have one successful load of oaksetup_restore.bin after many attempts – also cycling the power between attempts. I then tried firmware_v1.bin, but the same random results with zero success.

Code: [Select]

F:\Installs\Oak\LocalUpdater\OakRestore-master>esptool --baud 115200 --port COM5 write_flash -fs 32m 0x1000 blank.bin 0x2000 oaksetup_restore.bin 0x0081000 oakupdate_restore.bin 0x101000 blank.bin 0x102000 blank.bin 0x202000 blank.bin
Connecting...
Erasing flash...
Wrote 4096 bytes at 0x00001000 in 0.4 seconds (73.3 kbit/s)...
Erasing flash...
Writing at 0x00024800... (52 %)
A fatal error occurred: Invalid head of packet

F:\Installs\Oak\LocalUpdater\OakRestore-master>esptool --baud 115200 --port COM5 write_flash -fs 32m 0x1000 blank.bin 0x2000 oaksetup_restore.bin 0x0081000 oakupdate_restore.bin 0x101000 blank.bin 0x102000 blank.bin 0x202000 blank.bin
Connecting...
Erasing flash...
Wrote 4096 bytes at 0x00001000 in 0.4 seconds (73.3 kbit/s)...
Erasing flash...
Wrote 271360 bytes at 0x00002000 in 29.7 seconds (73.1 kbit/s)...
Erasing flash...
Writing at 0x000a8800... (62 %)
A fatal error occurred: Invalid head of packet

F:\Installs\Oak\LocalUpdater\OakRestore-master>esptool --baud 115200 --port COM5 write_flash -fs 32m 0x1000 blank.bin 0x2000 oaksetup_restore.bin 0x0081000 oakupdate_restore.bin 0x101000 blank.bin 0x102000 blank.bin 0x202000 blank.bin
Connecting...
Erasing flash...
Wrote 4096 bytes at 0x00001000 in 0.4 seconds (73.3 kbit/s)...
Erasing flash...
Wrote 271360 bytes at 0x00002000 in 29.7 seconds (73.2 kbit/s)...
Erasing flash...
Wrote 259072 bytes at 0x00081000 in 28.3 seconds (73.2 kbit/s)...
Erasing flash...
Wrote 4096 bytes at 0x00101000 in 0.4 seconds (73.1 kbit/s)...
Erasing flash...
Wrote 4096 bytes at 0x00102000 in 0.4 seconds (73.3 kbit/s)...
Erasing flash...
Wrote 4096 bytes at 0x00202000 in 0.4 seconds (73.3 kbit/s)...

Leaving...

F:\Installs\Oak\LocalUpdater\OakRestore-master>esptool --baud 115200 --port COM5 write_flash -fs 32m 0x1000 blank.bin 0x2000 firmware_v1.bin 0x101000 blank.bin 0x102000 blank.bin 0x202000 blank.bin

F:\Installs\Oak\LocalUpdater\OakRestore-master>
F:\Installs\Oak\LocalUpdater\OakRestore-master>esptool --baud 115200 --port COM5 write_flash -fs 32m 0x1000 blank.bin 0x2000 firmware_v1.bin 0x101000 blank.bin 0x102000 blank.bin 0x202000 blank.bin
Connecting...
Erasing flash...
Wrote 4096 bytes at 0x00001000 in 0.4 seconds (73.3 kbit/s)...
Erasing flash...
Writing at 0x00013000... (9 %)
A fatal error occurred: Invalid head of packet

F:\Installs\Oak\LocalUpdater\OakRestore-master>esptool --baud 115200 --port COM5 write_flash -fs 32m 0x1000 blank.bin 0x2000 firmware_v1.bin 0x101000 blank.bin 0x102000 blank.bin 0x202000 blank.bin
Connecting...
Erasing flash...
Wrote 4096 bytes at 0x00001000 in 0.4 seconds (73.3 kbit/s)...
Erasing flash...
Writing at 0x0001e400... (15 %)
A fatal error occurred: Invalid head of packet
Notes:
I did away with trying to flash it on a breadboard and built a custom cable harness to connect the Oak to the FTDI adaptor, just in case there was some intermittent electrical connection.
Power rail is stable at 3.3V and very clean as observed on my scope.
Current availability is 1A, so there should not be a problem there.
Running Windows 10.
I have only tried 2 of my 10 Oaks in case I brick them in the process.
I have tried 2 different FTDI adaptors – both of which are known to work fine with other MCU projects.
I have spent 6 hours going round in circles…

Would very much appreciate any guidance.

[exeng]

That error sounds vaguely familiar. I think I encountered it the first time I used the esptool. I want to say it was something very simple but can't remember what.  Are you sure that your FTDI adaptor is coming up on COM5? Check that. Sorry I couldn't be of more help but if comes back to me I will respond.

[defragster]

Bummer on the grief.  I assume you had the proper Rx/Tx cross and your adapter has led's showing you were getting PC Tx and some Rx responses from the OAK before it failed?

I got my BETA in FEB to WWW update & register.  I got my final 6 when the LiPo's shipped for some reason all looked to start with the WWW update - two even went to the 3 blink - but none registered.  I have previously flashed with FTDI to Generic ESP8266's (using Arduino) - but for OAK decided to try the LOCAL server method so I wouldn't have any chance of going from bad to worse if I got the wrong .BIN files.

I set up for the LOCAL server method and had all 6 work in the end to register - even repeated it on my Feb Beta 'BETA' OAK (to wipe Beta firmware) so all 7 could take updates using the IDE.

My summary using the LOCAL update under Windows10 is in this thread: http://digistump.com/board/index.php/topic,2103.msg9700.html#msg9700

Hopefully it will work for you.

[defragster]

Wrong port or baud mismatch would be a problem - my note on the FTDI LED and response would clear that up.  If the OAK sends back enough to get going it should be set.  But it looks like a series of 'Wrote ### bytes' succeeded.  Of course I tried LUA and ESP firmware on my breadboard and they ran swimmingly -but never worked.  I moved onto Arduino - that also failed - then I saw my voltage to the ESP was 2.5V so I doubled up breadboard wires to 3V3/GND and got the right voltage and did repeated flashes to about 6 different generic ESP units.

[Mr.B]

@exeng:
Definitely COM5… I have verified this on another MCU project. Also, the second FTDI adaptor I tried was assigned COM9 by Windows. Changing the command line syntax for that COM resulted in similar results… The esptool software talks to the Oak, however it fails randomly into the process.

@defragster:
Yes, Tx/Rx are connected properly and LEDs are behaving as expected… As I said in my OP, I have extensive electronics experience and the beginners traps of Tx/Rx reversed are the first things I double check… That said, no offence for trying to help…
The Oak is definitely communicating with the esptool software as it always gets some way into the process before it fails.

“Wrong port or baud mismatch would be a problem”…
Yip… I tried different baud, but only the 115200 would communicate – further research tells me that that is the only baud option for the ESP module up front. Also, definitely the right port… As I said above, it is communicating, just not finishing the job.

Who wrote “esptool”?
Is it opensource?
I need to find out what the error message “Invalid head of packet” means…

Many thanks for any pointers to some help.

[PeterF]

@Mr.B : Since your adapter works for other projects, this probably isn't the issue, but is always worth checking to remove it from the list of possibilities... So, it might be worth checking your  be worth double checking your FTDI converter driver - as you may have been 'upgraded' to the new driver, and if your FTDI board has a 'fake' chip - it will be getting junk on the RX "NON GENUINE DEVICE FOUND!". To check, just open up the Arduino IDE, and with nothing connected to the FTDI chip, if you get that message on the serial monitor, then you have been affected. Workaround is to roll back the driver version. Best option is to boycott FTDI and get CH340 or other USB to serial chips. This message ruins the esptools day as it is only looking for confirmation messages from the chip to indicate successful writes - not "NON GENUINE DEVICE FOUND!" junk.

Pete

[defragster]

@Mr.B - you noted your experience already - that's why I said 'I assume ...' - the question was more to your hardware, and making sure I wasn't assuming something I couldn't see. Almost offended you'd consider being offended.  And as noted I worked a full day on generic ESP's with well blinking LED's and UPLOADS reported as 'working' - but low voltage must have kept the 'burn' from happening even though it all seemed well.  But in that time I never got a failure code from the ESPTOOL to think it was not working.

A quick web search finds this for ESPTOOL source: https://github.com/themadinventor/esptool [ one other github that came up was forked from this ]

I took the LOCAL SERVER route as it seemed to emulate the normal WWW cloud upload only without the round trip to WWW - and it worked faster and well.

[Mr.B]

@pfeeick:
Yes, well aware of the FTDI-gate ‘bricking driver’, followed by the ‘refuse to work driver’. I have half a dozen assorted FTDI USB to serial converters and so far all devices are proven to be genuine. The Arduino IDE is happy with all of them. Future designs of mine that would normally have used the FTDI232 chip will definitely not be doing so in the future…

@defragster:
I will have another go at the LOCAL SERVER method and see what can be revealed with Netmon.

Many thanks all.