OTA image magic bytes and data alignment

[rfleming]

Hi All,

I currently have an http webserver running on my esp32 pico. When I parse an OTAU .bin file from the webpage to the esp32, I outputted all the data and disabled the debug messages. Did a comparison with the original final and they match identically. My issue is that the magic byte error appears when I try to do an OTAU.

Currently I am not handling the error from esp_ota_write, so I obviously get a lot of magic byte errors appearing:

Code: Select all

{1B}[0;31mE (52101) esp_ota_ops: OTA image has invalid magic byte (expected 0xE9, saw 0x0a){1B}[0m
{1B}[0;31mE (52104) esp_ota_ops: OTA image has invalid magic byte (expected 0xE9, saw 0x64){1B}[0m
{1B}[0;31mE (52108) esp_ota_ops: OTA image has invalid magic byte (expected 0xE9, saw 0x3b){1B}[0m
{1B}[0;31mE (52116) esp_ota_ops: OTA image has invalid magic byte (expected 0xE9, saw 0x45){1B}[0m

Nonetheless, since I can confirm that my bin image is correct I started looking into the source for this function, could anyone please confirm that I require my buffer to be aligned correctly with the image. That is any occurence of 0xE9 must be at the start of the frame? 0xE9 the magic number in my .bin file only exists at the following locations:

Code: Select all

0
180
53046
53369
53571
53731
53777
64669
76764
...etc

So not exactly on the 256 byte boundaries.

Cheeky extract from esp_ota_write

Code: Select all

if (...data_bytes[0] != ESP_IMAGE_HEADER_MAGIC){

My data doesn't explicitly align with these boundaries. In some situations due to how I wrote my driver I could write as little as 1 or 2 bytes to this function, but I could also write up to 512 bytes (max buffer size). Looking into the ota examples at the native one, nothing really pops out different to the way I am doing mine atm except the write sizes.

I was also fascinated at how the driver stripped the boundary data from the start and end of the http transfer. I wrote my own stripper and functionally it appears to work 100% and delivers the entire file in the correct format and size, but means my buffer could get divided up into any size between 1 and 512 like stated above. Either that or they simply skip the first 4 new line characters and write the bin file including the final boundary value because it won't effect the actual code?

Looking forward to anything that could help me with my silly issues.

Cheers,
Ryan.

[rfleming]

Scrap that.

My entire data had a single leading 0xa that offset everything. After skipping this character it appears to work.