Firmware Updates from SD card not always working

[EDsteve]

@LIFsCode @OOHehir Just realized that the update process from SD card doesn't seem to always work. The LEDs are flashing as they should indication an update. But the log file shows errors as you can see in this log: Failed_Update-Log.txt

We updated all firmwares for the ELOCs from SD card without checking the serial monitor. So this issue might be the reason for the reboots in Jambi as discussed here That might also explain the older dates from the log files shown in the pictures from the discussion?

After 10 tests I haven't figured out yet when it works when it doesn't. Because it definitely works sometimes and sometimes it doesn't. But maybe you can find it out faster than i do looking at the log file? :)

This is the content of the SD card i used to update the ELOCs for Jambi. I made the doUpdate.txt file Read-Only so we were able to use it without adding the txt file after every update. Jambi_firmware.zip

[OOHehir]

@EDsteve @LIFsCode OK, is this a priority issue or should we incorporate it into the upcoming discussion about updating via Bluetooth? It seems it'll be overlapping, so unless it's necessary, it might be fixing something that could possibly be replaced.

[EDsteve]

@OOHehir @LIFsCode Definitely priority. It's a lot of effort to get the ELOCs out in the jungle. So they should work. If it takes less than one week to make the BT update work. I would choose the BT route. But thats wishfull thinking i guess? :)

Let's see what @LIFsCode says about this issue and then we decide what we do.

[LIFsCode]

@OOHehir @EDsteve This is nothing special for the SD card update but rather a general issue with the OTA update and its usage:

The Update process is checking its internal partition date and checks it against the date code of the binary. If the partition date is newer than the binary date the update process is aborted:

I (8825) UPDATE: /sdcard/eloc/update/elocupdate.bin: File creation date: 1708541822
I (8829) UPDATE: Update partition: 'partition1' at offset 0x7f0000 with size 0x7e0000
I (8837) UPDATE: compilation_date:Feb 29 2024
I (8842) UPDATE: compilation_time:10:40:05
I (8847) UPDATE: buf concatenated Feb 29 2024 10:40:05
I (8862) UPDATE: partition creation date/time in unix timestamp seconds is  1709203205
I (8870) UPDATE: partitionDateTime is greater or equal to fileDateTime, returning false
I (8879) UPDATE: esp_begin result = ESP_ERR_INVALID_ARG

This is done for security reasons. The partition of the SPIFFS must match with the partition information with which the binary file is created. If the partition date is newer than the binary date this is a hint, that the partition information might have been modified in between. However this is a hint not a proof. As far as I know it is not possible to retrieve the partition info from the .bin file.

For safety reasons we abort the update if the partition info is newer than the binary to prevent potentially bricking the ELOC. This is a very conservative aproach and can discussed to be less strict, but this adds risk of bricking ELOCs if changing partitions.

The mentioned approach also prohibits downgrading via OTA, which might be a requirement, I don't know. If this is a requirement this check should be removed

@EDsteve What I assume has happend here is: Did you maybe flashed the ELOCs via VS Code and then updated them via SD card with a previous generated .bin file? The timestamps are:

• Partition timestamp : Thu Feb 29 2024 10:40:05
• elocupdate.bin timestamp: Wed Feb 21 2024 18:57:02

[EDsteve]

@LIFsCode

hat I assume has happend here is: Did you maybe flashed the ELOCs via VS Code and then updated them via SD card with a previous generated .bin file?

You are correct. That's what happend. So yea. That explains it. Good to know this savety feature. Was hoping that would explain also the reboot issues in Jambi. But no luck. :)

I will close this now.