How to protect non-volatile data from mass erase?

[M F]

Posted on July 04, 2017 at 10:50

Hello everyone,

we need to protect certain calibration data we store in a STM32L051 microcontroller from being deleted by mass erase operations.

The scenario is as follows:

1- Our production stores some calibration bytes together with a firmware in the microcontroller non-volatile memory. The calibration information is device specific. This calibration values should not be deleted, as indicated, in the entire life of the device.

2- Our customer receives this microcontroller together with an API from us. He/she then creates his own application with the help of the API. Once created, he/she downloads his/her application in the STM32L051 microcontroller, replacing the default firmware from our production.

The question again, how to prevent that the calibration data is not lost if a mass erase is performed?

Thanks in advance for your ideas!

MF

[AvaTar]

Posted on July 04, 2017 at 11:25

The question again, how to prevent that the calibration data is not lost if a mass erase is performed?

In regard to Flash, this is self-contradicting.

Use the internal EEPROM, or external EEPROM/Flash, or provide an interface to save/restore this parameters to a host PC via your application.

[M F]

Posted on July 04, 2017 at 11:41

Thanks AvaTar,

A mass erase erases the data in EEPROM also.

[M F]

Posted on July 04, 2017 at 13:49

Actually. we don't 'want' a mass erase, AvaTar. However, a mass erase may happen

accidentally

when our customer reprograms the microcontroller.

A typical situation is when the device is read protected (Level 1). In this situation, if you try to reprogram the microcontroller, a programmer like the SEGGER j-link performs first a mass erase and then programs the chip. The calibration data is lost, therefore.

[AvaTar]

Posted on July 04, 2017 at 11:58

I didn't try that on a L152, and opinions might differ if this makes sense...

However, why do you want a mass erase ?

A block-wise erase under control of your application (bootloader ?) would make much more sense.

[AvaTar]

Posted on July 04, 2017 at 14:18

I think that puts us back to the self-contradiction.

I bet the mass erase is a system ROM routine like the bootloader, and cannot be modified.

You might ask ST directly, though.

IMHO you can't protect your customer from shooting himself in the foot, i.e. erasing his calibration data through carelessness. Giving him the opportunity to save/restore those data from within your app would fulfill this requirement - in my opinion ...

[M F]

Posted on July 04, 2017 at 16:48

I believe, there is a bit of misunderstanding, AvaTar. It is not our customer's calibration data that is erased: it is the calibration data that we stored in the controller that we would like to preserve. My original question wants to explore the possibility to find a way to store data as in a One-Time-Programmable memory, i.e. once stored is not possible to erase it, not even through an accidental mass erase.

However, if there is no way, maybe we have to write an application note for the customer how to save/restore the data, as you indicate. That can be an idea.

[Andrei Chichak]

Posted on July 04, 2017 at 19:09

Perhaps the OTP area is what you are looking for.

I have not used it, and won't be able to help further, but it gives 16 x 32 bit values. Perhaps that is enough for your config data.

Another possibility is to use an external FLASH and put a gap in the trace that goes to the write pin. Then put a pull up resistor on the write pin. At the factory, jumper the write pin, do your writes, then remove the jumper.

Andrei

[AvaTar]

Posted on July 04, 2017 at 18:33

It is not our customer's calibration data that is erased: it is the calibration data that we stored in the controller that we would like to preserve.

That doesn't make a difference regarding the effects of a mass erase.

Not sure if an external EEPROM would be an alternative, pricewise. The save/restore API would be the alternative.

Either spending more money for hardware, or for SW development ...

[Tesla DeLorean]

Posted on July 04, 2017 at 18:55

I think he gets that. So unless you keep a copy as part of your manufacturing/test process, which you can provide to your customer later, the best course of action is for your PC side programming tools to automatically save this critical data in a database linked to the unique ID of the parts. 

Own the programming of the part, through software and loaders, so you reduce the chance of someone bricking the part. The things you can manage from the outset will reduce the support headaches later.

Some STM32 parts have OTP, this tends to be limited