“Wear” retentive variables on SlimLine

[Ed Zobec]

I searched for information about it but couldn't find an answer. Come on SlimLine (specifically, I work on SlimLine Cortex M7 code MPS056A120) there is the possibility of having the retentive variables in memory positions from 2048 to 4095. So far everything is clear.

But is there a maximum number of writings of these variables to take into account - a bit like what happens with SD cards - before the physical module on which this functionality is developed fails? Or, put in other words, is it wise for my program to write a new value of a retentive variable at each slow cycle, risking finding the system unstable in a few months or years?

I wanted to allocate the addresses of the variables so that the web server could read them and thus make the current values ​​of the system available on the network. But actually not all the variables I declared need retain. The fact that I declared them all in the 2048 – 4095 range made me open this reflection.

If one wanted to manually declare the addresses of the variables, but did not want to damage the module that hosts them by continuously writing them, what should one do? Allocate them in the range 4096 – 6144?

But then perhaps you discover that to write a variable the entire memory is written and therefore there is always the same wear - whether 1 or 20 variables are written the module must erase and rewrite itself.

Or maybe everything is already so calculated that whatever you do, retentive memory has such a long life that it doesn't pose any problems...

[Enrico Viviani]

I'm answering to the best of my knowledge and from personal experience. Retentive memory should be on FeRam which promises a minimum of 10^10 cycles. Being similar to DRAM, it also requires two cycles for reading because the latter is "destructive" for the data contained.

From personal experience, retentive variables rewritten at least a thousand times a day for, so far, almost ten years have caused no problems.

[Ed Zobec]

Since I was working on a different project on a completely different architecture (ESP32), where I have to save variables in memory, and since they advise not to exceed 10 writes, I had this doubt for some projects that I maintain with the SlimLine.

Reviewing the code I wrote at the time for this SlimLine, I declared global variables in the memory range 2048 – 4095 and thus obtained their persistence. On some it was intentional, and being user input there are no problems with the cycles. Others, however, are readings from connected sensors and change value with each slow cycle (10x per second). I'm not interested in persistence on these, as they can very well be recalculated when turned on again. 10^10 seems infinite, but at the rate of 10 writes per second that's 32 years of life. Acceptable, but I think it's not the correct way to proceed.

So question: if I want to continue allocating variables manually, and I don't want them to be persistent, should I do it in the memory range 4096 – 6144? Obviously always respecting the divisibility of the address, that is clear to me.

And, at this point, out of curiosity, what is the memory from 0 to 2047 for? If I allocate variables here, what happens?

[Sergio Bertana]

Meanwhile we come to FRAM memory, in SlimLine is used FM25V02A of Cypress which from the datasheet guarantees:

• High-endurance 100 trillion (10^14) read/writes
• 151-year data retention

But in your specific application it is rightly useless to allocate variables in backup memory that do not need to be maintained, so you can allocate them right in the DB100 in the range from 0 to 2047. In fact the DB100 area is divided into two parts of 2048 bytes, the first part from 0-2047 is not buffered, the second part from 2048-4095 is buffered in FRAM.

Global variables are allocated manually in DB100 only if they must be manageable by Modbus (Example operator panel), otherwise they can be defined Auto delegating their allocation to LogicLab. Even the variables Auto they can be maintained at shutdown, just declare them RETAIN, and also in this case they will be supported on FRAM.

The RETAIN variables, unlike those allocated in the DB100, although maintaining their value when the system is turned off, are initialized when a new program is loaded (See topic).

[Author]

Post