What are possible reasons for NVM data corruption during embedded controller shutdown?

[jani12]

Typical embedded ECU stores real calibration values and default calibration values in Non-Volatile Memory(NVM).

Let's say ECU is Steering Controller and it's primary function is Lane Keep Assist(LKA). It is mounted in a commercial truck. It programs camera's real and default calibration values in NVM.

Mostly, real calibration values are used. When and why are default calibration values used?

 

[FvM]

Typically default values are constants in code flash, not residing in NVM. They are used in lack of a valid calibration, e.g. if the device hasn't been yet calibrated or NVM is corrupted (CRC error detected).

 

[jani12]

Consider a typical autonomous embedded Steering Control Module. This controller is mounted in a Commercial Truck. It assists in keeping the vehicle in it's lane.

During transition to sleep mode, real camera calibration data is written from RAM to NVM. This data written to NVM is corrupted. What are possible reasons that corrupt NVM data?

1. Brown out condition
2. Reset
3. Power loss
4. Any other reason that cause NVM corruption during controller transitioning to sleep mode.

How to find out if NVM data is corrupted? After controller wakes up, does it calculate checksum of real calibration values in the NVM and if calculated checksum doesn't match checksum stored in NVM, it is concluded that NVM is corrupted?

 

[KlausST]

Hi

What is the situation?
Microcontroller --> SPI or I2C --> external NVRAM?

If so:
* The microcontroller may run into low voltage before the whole dataset is written
* The microcontroller may erroneously perform a different/additional write access befor the power down
* Or one of both at power up
* Power loss before NVRAM finished write process

How I do it:
* detect early power loss
* install capacitors to sully only the circuitry needed for wrting data to NVRAM
* install proper RESET circuits to disable write access during low supply voltage (hardware)
* install HW to disable write access during microcontroller boot (sometimes just a pullup /pulldown is necessary)
* often I use one microcontroller port pin with external pulldown as SW_controlled RESET. External HW AND with power_supply_ undervoltage_detector.

In either case the NVRAM datasheet will tell you what you have to care for to prevent data corruption.

Klaus

 

[jani12]

Hello

If the situation is, Microcontroller --> SPI or I2C --> external NVRAM?

>> Microcontroller --> SPI or I2C --> external NVRAM?
Upon wakeup, software will read NVM data and calculate checksum. The calculated checksum will be compared with checksum stored in the NVM. If the checksums aren't identical, it means corrupted NVM data?

>> The microcontroller may erroneously perform a different/additional write access before the power down
If there is a bug in software, I can see this happening. Is there any other reason that would cause this to happen?

>> Or one of both at power up
On power up we don't write, we read first to find out if the in NVM is valid?

>> Power loss before NVRAM finished write process
Upon wakeup, software will read NVM data and calculate checksum. The calculated checksum will be compared with checksum stored in the NVM. If the checksums aren't identical, it means corrupted NVM data?

>> detect early power loss
What action to take if power loss is detected? If software tries to log power loss Diagnostic Trouble Code(DTC), it may not get logged because software an microcontroller may not operate during power loss. If software or hardware tries to force system reset, system reset may not occur because software and hardware may not be operational during power loss.

>> install proper RESET circuits to disable write access during low supply voltage (hardware)
Upon wakeup, software will read NVM data and calculate checksum. The calculated checksum will be compared with checksum stored in the NVM. If the checksums aren't identical, it means corrupted NVM data?

What if the situation is Data Flash internal to Microcontroller?

 

[danadakk]

When you write your cal data include in the last write a flag bit to indicate
that group of data was written, eg. any power loss did not affect it. If that
flag is not set but there is data present its to be ignored. You can even include
a start byte pattern to indicate a controlled write follows, and then conclude
with the flag or another end byte pattern. Couple that with your checksum
should be good insurance.

Best approach as previously stated is a cap that holds up power long enough
to finish a data set write. Only start a write if brownout is not detected. Make sure
no other interrupts can intercede with a write operation due to higher priority.
In fact I would be inclined to shut off all interrupts until dataset is written.


Regards, Dana.

 

[KlausST]

If the situation is, Microcontroller --> SPI or I2C --> external NVRAM?

Isi it? Or not?

Upon wakeup, software will read NVM data and calculate checksum. The calculated checksum will be compared with checksum stored in the NVM. If the checksums aren't identical, it means corrupted NVM data?

You first need to calculate the checksum and write it to the NVRAM. Before power down

If there is a bug in software, I can see this happening. Is there any other reason that would cause this to happen?

You will see a software bug. But you won't see a hardware problem. Maybe supply voltage out of specification. Or oscillator not stable.

What if the situation is Data Flash internal to Microcontroller?

I don't want to slove useless riddles. Plese tell us your situation.

What action to take if power loss is detected?

As already written. If you want good answers you need to give good informations first.

Klaus

 

[danadakk]

One additional thought.

If the IDE has APIs for doing the write to NVM they most likely have incorporated
the specific timing needed to do the task. But if you have to write the procedure
from scratch thats where interrupts from other running tasks can cause head aches.
Incorrect timing, depending on part, can cause memory cell issues.

Most modern parts take care of these issues, making them largely transparent to user,
but buyer beware, ask questions. Read chip architecture manual carefully.

Usually FAEs (vendor FAE) can handle questions on this topic from his/her training.


Regards, Dana.