A fatal error occurred invalid head of packet 0xe0

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:

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.

F:InstallsOakLocalUpdaterOakRestore-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

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.

Logged

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.

Logged

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.

Logged

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.

Logged

@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.

Logged

@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

Logged

@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.

« Last Edit: March 25, 2016, 09:38:02 am by defragster »

Logged

@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.

Logged

So here’s some update, I took some of the USB-Serial I have around and tested and you’re right. Somehow it works very nicely with CH340, PL-2303HX and FTDI232 however, testing again using the CP2102, it doesn’t work and gives that error Invalid head of packet ('xe0') hence, the NodeMCU that is also based on CP2102 is also showing this error.

Not a big issue, just change the FWBURNFLAGS = -b 115200 or FWBURNFLAGS = -b 1500000. If someone else can verify this then we can close this.

I can confirm that changing the setting to 115200 helped me. Using a CP2102 based dongle on osx 10.11.3

I think I’ll leave this issue open forever :-p

I can confirm this always happens with CP2102, while perfectly working with FTDI

Yep. 1500000 vs 1000000 vs 2000000 baud. When you get the crazy high speeds, it is device-dependent.

Where can I find the user.cfg file on Mac OS X?

Just wanted to chime in that by further reducing the baud rate from 115200 to 57600 it solved a similar issue:

Chip is ESP32D0WDQ6 (revision 1)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
MAC: xx:xx:xx:xx:xx
Uploading stub…

A fatal error occurred: Invalid head of packet (0x65)

thanks for leaving this open.
115200 worked for me.

Confirm to have issue, and solved by 115200 flashing speed for ESP32 (TTGO mini T7 v1.3)

Same issue on Geekworm KE-WROVER-C20 EASY KIT ESP32_WROVER 8MB PSRAM
fiddling with the boot button (labeled «USER» on this board) did not help
upload speed 115200 works well

Just wanted to chime in that by further reducing the baud rate from 115200 to 57600 it solved a similar issue:

Chip is ESP32D0WDQ6 (revision 1)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
MAC: xx:xx:xx:xx:xx
Uploading stub…

A fatal error occurred: Invalid head of packet (0x65)

In my case, the devkit was expecting 115200 and the idf was set to 460800

It is very unusual that 460800 is outside of a viable upload speed, but, with weird USB-serial chips that makes some sense.

Also, I am going to close this issue, since it is basically resolved for anyone who would care, and does not reflect an issue with the codebase.