ESP32 Forum

Is the ESP32 able to read its program memory for comparison to OTA memory? I want to make a memory scrubber to maintain program integrity for the longest possible time.
Thanks!

That does not make sense. An OTA capable ESP32 has the flash divided into two OTA partitions of which only one is active: the active one is used for the currently running version, the other is used to download a new version in (and generally holds an old version if no OTA is in the process of downloading). In other words: for the active program, the OTA memory *is* the program memory.

Is there a particular reason you're concerned about the integrity of the program memory over time? What specific problem are you trying to solve?

If your application currently uses OTA, I suppose after first successful boot after a firmware update you could copy the active partition to the other OTA partition in your application and use that as your redundant copy. The (I guess) you would occasionally compare them (I'm not sure of your intentions specifically). The roles of the OTA partitions will reverse on the next OTA update as usual. It's a bit unorthodox to do this with the OTA partitions and I've given it all of 10 seconds of thought so I'm not sure if it would work.

Thank you for your responses mbratch and ESP_Sprite. mbratch, you suppose correctly about my intended operation.

Based on my limited research, it seems that the charge in Flash cells gradually dissipates, and eventually errors are likely, if not certain. I would like to assure the proper operation of my device after one of these errors occurs. I'm working on a residential cooler controller which (if I do my job right) will likely end up being in place for decades. So I want to be able to compare the two OTA partitions and identify errors soon after they occur, so that the device can repair itself and continue operating in the absence of external updating.

I should be able to identify the two OTA partitions from the partition map, but I need to figure out how to read an arbitrary memory location. Once I can do that, I can build a model to test this concept for a memory scrubber.

Thanks again!

You can read those partitions using esp_partition_* API calls.

Note that you may want to test the behaviour on memory corruption first; you may not even need to do a compare. When the ESP boots, it tends to use a CRC or hash to figure out if the current OTA partition is corrupted; it'll try to boot the other OTA partition (if valid) and then the factory partition if that happens. As long as OTA keeps working, that'll probably get you where you need without any modifications: if the older OTA and/or the factory partition automatically grab the latest firmware from the Internet, the issue will fix itself.

nnangeroni wrote: ↑

Thu Jan 05, 2023 8:11 pm

I should be able to identify the two OTA partitions from the partition map, but I need to figure out how to read an arbitrary memory location.

As ESP_Sprite says, check out the esp_partition functions. You can read any amount of a given partition starting at any offset (although I think it's got a particular block size which is how flash is structured, so your offsets have to be on a block boundary and you need to read an integer multiple of the block size in bytes, I think...). It's all there in the documentation.

Thank you, mbratch, I appreciate the helpful affirmation!

Back after a long break...

ESP_Sprite wrote: ↑

Fri Jan 06, 2023 1:19 am

You can read those partitions using esp_partition_* API calls.

When the ESP boots, it tends to use a CRC or hash to figure out if the current OTA partition is corrupted; it'll try to boot the other OTA partition (if valid) and then the factory partition if that happens.

Those esp_partition_* API calls, according to the doc, are for external flash, not the onboard program flash. (Maybe I'm confused?)

The Application Startup Flow documentation (https://docs.espressif.com/projects/esp ... artup.html) doesn't mention anything about a CRC check at boot time. Can you point me to some documentation that verifies that behavior? Otherwise I'm still lacking a good solution to deal with long-term flash cell charge loss.

Thanks for any help!

The App Rollback feature may be helpful.

nnangeroni wrote: ↑

Mon Dec 18, 2023 11:31 pm

Those esp_partition_* API calls, according to the doc, are for external flash, not the onboard program flash. (Maybe I'm confused?)

What part of the doc leads you to believe this? The partition functions do work with partition that is in internal flash. I use them on my project.