Collision with OTA Update RTC Address Space

[bwjohns4]

Using the RTC_BASE of 28 interferes with the Arduino OTA update. The update process uses the 1st 128 bytes of RTC (link) to signal to the bootloader details of the OTA update. I found that OTA updates stopped working after using this library. I have changed RTC_BASE to 132 in my application to see if this corrects the problem.

[highno]

Thanks for noticing that. In my opinion there should be a configurable option to be OTA safe and have less memory for rtcvars.

Do you know a safe way to detect whether OTA is used in a sketch?

[bwjohns4]

#7 I Submitted a PR with the correction that I used. I'm not sure how best to detect if OTA is being used, but since it only increases the base by 5 slots (20 bytes) it may not be enough to warrant a more elaborate detection mechanism.

[highno]

Your interpretation of my code does not follow the original intent. The slots are actually of dynamic size and not stuck to 4 bytes. The byte count at the beginning actually means bytes, not 4-byte elements. I was excluding the area that the real RTC uses. I would prefer to stick to that byte counter and so, actually set it to 128 instead of multiplying by 4. It is just a coincidence that it seems to go well with the 32 slots for variables. That 32 entries is an arbitrary number picked to be enough to be flexible but small to keep memory impact of the variable address table low. If your state, by any reason, needs to store 400 byte values - you sure can put all those in the state, but need to adjust that variable maximum.

[bwjohns4]

I had originally set RTC_BASE to 132 (to get past the 128 bytes used by OTA) but I couldn't get RTC to work at all when doing that. Then I looked at the implementation of:

bool EspClass::rtcUserMemoryWrite(uint32_t offset, uint32_t *data, size_t size)
{
    if (offset * 4 + size > 512 || size == 0) {
        return false;
    } else {
        return system_rtc_mem_write(64 + offset, data, size);
    }
}

this implies that the ESP.rtcUserMemoryWrite function interprets the offset as a multiple of 4 bytes. So I would interpret that to mean that in this library when doing: ESP.rtcUserMemoryWrite(RTC_BASE, (uint32_t*) &buf, _state_size + 1); the RTC_BASE would be an offset of a multiple of 4 bytes, right?

Please let me know if I'm missing something. OTA works after changing from RTC_BASE 28 to RTC_BASE 33 which multiplied by 4 is 132 (4 bytes of padding above the OTA space). But RTC does not work if I put RTC_BASE at 132 or more.

[highno]

I have to investigate further to confirm your finding. It sounds very plausible and I am irritated if I missed something right from the start. I'll keep you informed here.

[oscarfuentees]

Does it support OTA updates? @highno @per1234

[bwjohns4]

With the shift proposed in the #7 PR it does indeed support OTA. Otherwise it collides with the OTA process.

[fabianoriccardi]

Thanks @bwjohns4 for pointing out the issue! I have just taken the opportunity to fix and improve the RTCMemory library.

[Jaybee2020]

Has this problem been resolved? I just installed the library and could not find any problems with the OTA update. It seems to work fine. I use the "traditional" OTA update for the ESP8266 as well as the library AsyncElegantOTA. Both variants work properly, even after writing some variables to the RTC ram with the rtcvars library.