3

Having a skech running on ESP8266 as well as ESP32 with the ability to update via OTA, uploading the wrong binary (upload to ESP8266 compiled for ESP32, and vice versa) leads to crashing the MCU and not being able to do OTA Updates any more.

The Update is done in the simple usual way: Upload binary file and call the methods from the Update Class (begin(), write(), and end()).

Is there any way to check if the uploaded file matches the architecture of the MCU before starting the update?

Edit:

Both the ESP8266 and the ESP32 Updater class check for an "IMAGE_MAGIC" value in the upload header; but that is defined as "ESP_IMAGE_MAGIC = 0xe9" in both cores. So none of them will refuse to update the wrong one.

Edit 2:

Found a simple workaround that satisfies our needs at the moment: As the arduino IDE saves the binaries with a name like <sketch_name>.<board_name>.bin, we just compare the board name as part of the uploaded filename: if (upload.filename.indexOf(MATCH) > 0) ..., where MATCH is the respective board name. As they are pin compatible, we use "d1_mini.bin" and "d1_mini32.bin".

Edit 3:

When the webserver tries to abort the upload with 403 Forbidden (because of wrong file), the browser continues to send data until the upload is done. After that, it displays the error message. Thus, even when the filename does not match, it is a waste of time and bandwidth. The only possibility to avoid this is to do a server.client().stop(), but then the browser will not display the message sent, just something like "connection broken". This does not confirm with the respective RFCs.

This is not really a final solution, so I'ld appreciate any better idea.

Richard

Improve this question
3
  • You could just try what happens if you perform such an "illegal" update. My guess is that booting an image intended for the other MCU would fail and be marked as corrupted firmware image. If esp8266 and esp32 have different flash sizes I would expect the bootloader to recognize the faulty firmware images
    – Sim Son
    Commented Jan 1, 2021 at 0:35
  • At least I once OTAed a 4MB-ESP32 with an image intended for an 8MB-ESP32, which failed (the esp declined booting this image and remained on the fw-version that was installed previously)
    – Sim Son
    Commented Jan 1, 2021 at 0:38
  • The bords we use have the same amount of flash size (4MB), and the updater class of the ESPs seem to accept any file as long as the "magic byte" is 0xE9, but that is the same for ESP32 and ESP8266. Tested this with small text file named "fake.d1_mini.bin" wth 0xE9 as first byte - did report no error on update, but crashed on reboot.
    – ridgy
    Commented Jan 2, 2021 at 13:27

1 Answer 1

Reset to default
1

I assume you are the one creating the OTA update. If so, then why don't you just include a "signature" in the code that is the architecture, i.e. ESP8266 vs. ESP32 and then check for that in your updater code so that it will not install an update for the wrong CPU.

Improve this answer
2
  • 1
    Thank you for your answer. This was also my first idea, but finding a signature somewhere in the uploaded file is a lot of work, as you do not know where the linker puts the signature. I thought of a simpler method...
    – ridgy
    Commented Dec 30, 2020 at 20:38
  • You can force the linker to place a signature at a specific location. Or you can "abuse" an unused interrupt vector.
    – the busybee
    Commented Dec 31, 2020 at 10:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.