ESP32 changes placed in RTC memory variables after returning from deep sleep

[Paul_Rodopi]

Dear colleagues,

I will appreciate you help in solving the following problem I encounter when programming my ESP32 Lolin32 board.

I have defined a structure in RTC memory for keeping calculated up to six time offsets between SNTP and RTC time:

typedef struct
{
struct timeval offset_t[ESP_MAX_TIMESYNCS]; // array of time offsetts
int index_t; // current time offsett index
} time_offsets;

RTC_DATA_ATTR static time_offsetts all_offsets;

The structure is filled correctly up to the last time offset with index 5, when, by some reason ESP 32 changes
the value of timeval structure seconds part in the record with index 0 to one and the same value of 1073507920.

Index is 4:
Time offsett 0 has 1 sec, 757791 usec
Time offsett 1 has 3 sec, 369129 usec
Time offsett 2 has 4 sec, 308570 usec
Time offsett 3 has 4 sec, 45207 usec
Time offsett 4 has 3 sec, 521489 usec
Time offsett 5 has 0 sec, 0 usec

Index is 5:
Time offsett 0 has 1073507920 sec, 757791 usec
Time offsett 1 has 3 sec, 369129 usec
Time offsett 2 has 4 sec, 308570 usec
Time offsett 3 has 4 sec, 45207 usec
Time offsett 4 has 3 sec, 521489 usec
Time offsett 5 has 0 sec, 535202 usec

I carefully reviewed and debugged my code many times. The RTC memory for this variable seems correctly initialized
like:

memset(all_offsets, 0, sizeof(all_offsets));

and verified that it was.

But still cannot find a solution to this problem. Please advise me, how to solve this problem.

Thanks,

Paul

[ESP_Sprite]

1073507920 in hex is 3FFC6E50, which looks like a pointer. Are you sure you're not overflowing something else somewhere?

[Paul_Rodopi]

Yes, I missed to mention that I have defined two RTC_DATA_ATTR structures in two separate source files: main.c and the second with strange behavior, in a separate .c file. I observed earlier that the sequence of placing variables marked with RTC_DATA_ATTR is important for the compiler. For example, in main.c I had to place all RTC_DATA_ATTR variables in a sequence, as a block of data. Otherwise they got corrupted after wakeups from deep sleep. I suppose that there is something similar in this case. The structures in are handled in main.c like this: first is handled the structure in the second source file (with a function call from main.c), then is handled the structure in main,c locally. Each of these structures is handled six times. The change (garbage) in the second structure happens on the last (sixth) return from deep sleep. Most likely the last handling of the structure in main,c affects somehow the structure in the second source file. Is this behavior somehow related to some data offset in the RTC fast memory, where these structures reside? How I can fix this?

[ESP_Sprite]

Yes, I missed to mention that I have defined two RTC_DATA_ATTR structures in two separate source files: main.c and the second with strange behavior, in a separate .c file. I observed earlier that the sequence of placing variables marked with RTC_DATA_ATTR is important for the compiler. For example, in main.c I had to place all RTC_DATA_ATTR variables in a sequence, as a block of data. Otherwise they got corrupted after wakeups from deep sleep. I suppose that there is something similar in this case. The structures in are handled in main.c like this: first is handled the structure in the second source file (with a function call from main.c), then is handled the structure in main,c locally. Each of these structures is handled six times. The change (garbage) in the second structure happens on the last (sixth) return from deep sleep. Most likely the last handling of the structure in main,c affects somehow the structure in the second source file. Is this behavior somehow related to some data offset in the RTC fast memory, where these structures reside? How I can fix this?

Show your code, preferably whittled down to the minimum that still shows the behaviour that you see, and maybe we can tell you. Given the fact that RTC_DATA_ATTR is used in a fair amount of projects without issue and that the behaviour is dependent on something that is very specific to your use case, my bet is thay your code has a bug somewhere.