SAMD21J18A emulated EEPROM corrupted

Go To Last Post
2 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

I’m having trouble with the emulated EEPROM on SAMD21J18A getting corrupted.
To get an idea where to start finding the fault I hope someone can tell me what could potentially cause the corruption.
I use ASF. The hardware layout is according to the schematic checklist and very similar to the Explained Pro boards. My product is a device with several sensor/actor ports and some power sockets. The connections to the power sockets are isolated by optocouplers.

 

The EEPROM corruption happens in rare cases. (after days or weeks of operations)
I assume that it does not happen on all devices or not in all use cases.
One customer told me that it happened more likely with a switching power supply connected to one of the device’s power sockets. I don’t know if this is true, but it might sound like an EMC immunity problem.
I have now observed the corruption on a device that was running on my desk (EMC quiet environment) without any external connections except a WiFi board +USB cable to PC.
Before I realized the corruption, the device was re-booting.
The EEPROM is used to save settings and it is written once in a while. (No frequent writes/commits)
Since I’m trying to solve the problem for a while already, the EEP commit is done directly after the write. So, it is not done in BOD or WDT ISR.

When the corruption occurs the EEP is not erased in configure_eeprom() (see function below). But the read EEP data is corrupt. This is recognized by my program and the factory default values are written to EEP.

 

Since the device was re-booting, I assume a hard fault was causing the corruption. Because it happens in very rare cases, it is kind of hard to debug.

 

Can someone tell me what kind of situations, hard faults or programming failures could potentially cause EEPROM corruption?

What could be the reason for unintended NVM writing in the EEP region?

 

Thank you very much in advance

Tobi

 

enum status_code configure_eeprom(void)
{
	enum status_code error_code = eeprom_emulator_init();

    /* Setup EEPROM emulator service */

    if (error_code == STATUS_ERR_NO_MEMORY) {
        while (true) {
            /* No EEPROM section has been set in the device's fuses */
        }
    }
    else if (error_code != STATUS_OK) {
        /* Erase the emulated EEPROM memory (assume it is unformatted or
         * irrecoverably corrupt) */
        eeprom_emulator_erase_memory();
        eeprom_emulator_init();
    }
	return error_code;
}

 

Last Edited: Thu. Jul 29, 2021 - 06:25 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The EEPROM is only emulated, in fact it is flash memory.

So the problems come with flash memory limitations:

-you cannot pyhsically write one byte

-you need to erase memory sections

The eeprom emulation does this for you. If you take a closer look you will see that in the mcu your data is first written into a hardware buffer which is than copied into the flash memory.

This is the most critical point: If this process cannot be completed the eeprom will be corrupted.

Refereing to hard faults: in most cases hard faults happen due to alignment errors

 

For better debugging (and probably a more stable variant) I would suggest you to write a custom eeprom emulation with kind a history which would be your fallback if a write failed.

This would need more time (and more memory, so less eeprom memory would be available), but will help debugging and maybe also solving your problem.

 

In flash memory I could be implemented so that you have "old" rows that are deleted only if you have lets say two newer rows. Data is always written directly by changing only a few bytes and copying all old data.

If the write failed you can restore most of the data from the old rows.

 

Flo1991