I am concidering storing frame counters in memory when using ABP.
In many processors EEPROM memory is available. However this memory is average useable for 100.000 writes. At sending every hour one message, the AVR EEPROM will live 11 years which seems acceptable for a node. But at a interval of 1 minute the EEPROM will only live less that 3 month. What alternatives are there to overcome the problem of EEPROM in this case? any suggestions?
or memory combined with a real time clock
or use SPI flash, like WINBOND
Take a look at FRAM. For instance MB85RC04V, 512x8bit I2C storage which allows about 1E12 read/write cycles,
3 Likes
Why not do brown out detection an just store the value when needed?
Interesting suggestion. There are not much examples of brown out detection in combination with Arduino.
Questions that stay; When power is cut, will there be enough time left to write eeprom?
brown out detection is impossible to use if you use a buck/boost converter to create 3V3
I2C FRAM modules are commercially available and you can write whole day long 
Thanks guys, FRAM will save my day
I think this is the only serious alternative when you take control and write memory when it is relevant.
It will provide a guaranteed storage of information (unless power outage occurs while writing the FRAM 
)
Create two banks of data and write alternating the banks with a checksum. When reading check checksum and use the bank with the highest frame counter value.
It seems BoRRoZ’s kersing’s 
suggesting is great. Nevertheless:
Or if power outage should be rare: write only every, say, 100 values (so, store when it reaches 100, 200, …) and after recovering from a power failure take the stored value, add another 100, save that value and continue?
And if worried about 100,000 writes then also beware of rollover of the frame counters. 16 bits counters rollover at 65,536 and the specifications state:
The end-device shall not reuse the same FCntUp value, except for retransmission, with the same application and network session keys.
So I guess one needs to ensure 32 bits counters are used and select 32 bits in TTN Console.
(As an aside: note that the LoRaWAN header only includes the 16 least significant bits of the counters. But when selecting 32 bits counters in Console, TTN can increment the 16 most significant bits whenever the other 16 bits have rolled over. I guess that would even work if the node actually has 16 bits counters. And thinking about that, I wonder if a 16 bit header for a 32 bit value is prone to replay attacks… The full 32 bit counters are used in the AES message signature (MIC), so messages with rolledover counters will have different MICs than messages with the same 16LSB and payload before the rollover.)
2 Likes
the idea of the FRAM comes from Jac Kersing … 
2 Likes
That is also a good suggestion.
However I do not yet understand the purpose of writing a checksum and the mechanism you suggest.
I concidered to verify written data. When the data is not read correctly shift the position of the data to another place in EEPROM that is not damaged.
You mentioned being concerned about data corruption due to power failure while writing the data. Using a checksum allows you to detect corrupt data. Using two banks of data and writing to alternate banks reduces chances the data in both banks will be corrupt. (Just make sure never to write to the valid bank if the other one is corrupt so you will always have one valid set of data even if power fails again when writing)
1 Like
@kersing Good point. This method will increase both validity of data and expand life of EEPROM 2 times.
When I add my previous suggestion of moving memory at defection of checksum failure I have reached the optimum without adding hardware to the AVR.
You can also implement a brown-out detection, even if you are using a DC/DC converter. Just connect your ADC to the voltage input of the DC/DC (add a resistor divider if it is above ADC max), or use a comparator connected to an interrupt pin. When voltage drops FRAM saving will be triggered, and the DC/DC could have enough capacitance to let the microcontroller finish the write (otherwise add some caps).
Note that the 100k eeprom write cycles is according to the Atmel specs. However in practise the number is significantly higher. Check http://tronixstuff.com/2011/05/11/discovering-arduinos-internal-eeprom-lifespan/
Nevertheless I believe that the FRAM is a very good alternative.
in this setup I’ll try to use the fram as a kind of datalogger storage, taking meassurements at certain intervals and times (rtc) and store the result in fram.
2 Likes
Note that most modern micros don’t have EEPROM anymore, but emulate EEPROM in their internal flash memory and use native wear leveling. E.g. the popular Kinetis K20 has 32kb of flash (FlexNVM Freescale calls it) where you could emulate 2kb of EEPROM in, and the micro will juggle the bytes around making sure cells aren’t written to consecutively. This alleviates much of the write endurance problem.
1 Like
You can take a similar approach as the one on the SIM card.
Store the initial count number, then burn one bit for every messages, once memory is full, increase the initial counter, overwrite it, wipe the remaining of the memory and run another round. This can gives you, for an ATmega328P, based on the datasheet full 100000 cycles before thinking of ageing for a counter value of ~1 000 bytes * 100 000, so 100 000 000 messages (I kepts 24 bits for storing the counter and some additional values), or 3000 months for your last example.
Side note, 1 message every minutes is probably not realistic for LoRa in every cases.
Can one indeed address single bits when writing?
1 Like