EEPROM.commot() causes crashes

[bdring]

I have been getting an intermittent "Cache disabled but cached memory region accessed" crash. It only happens about 60% of the time. I have read everything I can find on this issue, but cannot find a solution that works for me. I have tried several methods including Preferences and the EEPROMClass methods.

I want to save a small struct to non volatile memory.

typedef struct {
	uint8_t settings_version; // stores the settings format version 		
	uint8_t led_brightness; 		
	uint8_t joystick_deadzone;
	uint16_t attack_threshold;	
	uint8_t audio_volume;	
	uint8_t lives_per_level;	
	
	// saved statistics
	uint16_t games_played;
	uint32_t total_points;
	uint16_t high_score;
	uint16_t boss_kills;	
}settings_t;

As I understand it, while I am saving to EEPROM, the most likely problem is, the memory gets lock and another task or interrupt is trying to load code into memory. I have only one Interrupt and I use IRAM_ATTR with that. I do use some libraries, that might have interrupts or tasks: Wifi.h, wifi_ap.h, FastLED.h.

The code is too big to post here, but it is on Github. The EEPROM code is in this file.

Bounty: I use this on an open source LED strip game. I would be happy to send some free hardware to the first person that helps me solve this issue.

[WereCatf]

Until this gets fixed, couldn't you use SPIFFS as an interim solution (if it doesn't cause the same crash) instead?

[buildlog]

Tried that. It has the same crash.

[everslick]

I had a short glance at the code, but could not spot an obvious error there. Nevertheless you complicate things a lot with using the temp buffer and memcopy...

I suggest getting a pointer to the data that is already allocated by EEPROM.begin() and casting that to a pointer to your settings_t struct...

first put EEPROM.begin(sizeof (settings_t)); in setup()

then get the pinter to the data:
settings_t *user_settings = (settings_t *)EEPROM.getDataPtr();

make *user_settings global if you want to have access to it from everywhere.

then you can do whatever you want e.g. ...

user_settings->games_played = 0;
...

when anything changes do EEPROM.commit()

no need to ever call EEPROM.end(); in your case.

hope this helps...

[WereCatf]

If he did it like that, the dirty-flag would never get set and commit() would never do anything. On 27. maaliskuuta 2018 19.01.46 Clemens Kirchgatterer <[email protected]> wrote: I had a short glance at the code, but could not spot an obvious error there. Nevertheless you complicate things a lot with using the temp buffer and memcopy... I suggest getting a pointer to the data that is already allocated by EEPROM.begin() and casting that to a pointer to your settings_t struct... first put EEPROM.begin(sizeof (settings_t)); in setup() then get the pinter to the data: settings_t user_settings = (settings_t *)EEPROM.getDataPtr(); then you can do whatever you want e.g. ... user_settings->games_played = 0; ...when anything changes do EEPROM.commit() no need to ever call EEPROM.end(); in your case. hope this helps... — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[everslick]

EEPROM.getDataPtr(); sets the dirty flag IIRC.

so just call EEPROM.getDataPtr(); before EEPROM.commit();

[bdring]

I think I found a fix. My sound.h file has an interrupt to create square wave tones. If I turn that off before the EEPROM write and back on after the write, it does not crash.

timerStop(sndTimer);
timerRestart(sndTimer);

I had tried noInterrupts(), but that did not do it.

I need to do a lot of testing because it was intermittent before, but so far, so good.

Thanks for all the suggestions.

[everslick]

noInterrupts() is a NOP on ESP32, AFAIK

[ermacv]

It's still opened so... You need to disable interrupts when you're executing EEPROM code. Or you can use mutex.

portMUX_TYPE myMutex = portMUX_INITIALIZER_UNLOCKED;
taskENTER_CRITICAL(&myMutex);
//EEPROM code
EEPROM.write(0, 123);
EEPROM.commit();
taskEXIT_CRITICAL(&myMutex);

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs. Thank you for your contributions.

[stale]

This stale issue has been automatically closed. Thank you for your contributions.