I m working on an nRF52840 µc ,the µc will be woken up every 3 hours and i have to save a data(4bytes) into a tab[16] so i can send those 16 values later after 2 days.
-
Am i able to save this much of data in a flash memory of 1024KB without damaging the code?????knowing that i will delete this data every 48 hours and rewrite again – Khalil Soltani Mar 23 '22 at 15:09
-
Do you switch off the power during sleep? If not, why don't you simply use RAM? – the busybee Mar 23 '22 at 15:22
-
@thebusybee, nRF52840 allows you to turn off power to the RAM banks without switching power off for the whole chip and it is best to do so for long battery life applications. – Fatih BAKIR Mar 23 '22 at 22:25
-
@KhalilSoltani, how much data do you need to save exactly? – Fatih BAKIR Mar 23 '22 at 22:28
-
These things need to be considered _before_ picking a MCU. Ideally you would pick one with EEPROM/data flash. Otherwise you have to write to program flash and that's always cumbersome, if at all possible. – Lundin Mar 24 '22 at 08:44
-
Everyone wants you to add an external EEPROM lol, just store your datas in flash. I do it in a lot of applications with nrf52 and I never had issues with it, ofc you have to erase the whole page and rewrite it – GabrielT Mar 24 '22 at 09:21
-
@GabrielT Or rather to be sensible and pick a MCU with memory-mapped data flash/eeprom actually intended for this very purpose. Writing to program flash is a pain in the neck. Better than external serial memories, sure, but far from ideal. – Lundin Mar 24 '22 at 10:35
-
That is: software engineering involves writing a specification and upon doing so considering the most exotic requirements. Writing to flash in run-time would be such a requirement, on-chip BLE would be another. _Then_ when you know what the MCU needs, you pick one accordingly. You cannot expect the hardware designers to understand things like the difference between program flash and data flash - picking the most appropriate MCU is largely the responsibility of the programmer(s). – Lundin Mar 24 '22 at 10:47
-
1And the opposite: bad engineering entails picking some random hardware found in a packet of corn flakes (often Arduino or some similar pestilence). Then once that's done, try to shoehorn the project into that unsuitable hardware. – Lundin Mar 24 '22 at 10:48
-
Would it not be possible to send the data every three hours and not to store it at all? That would be far simpler and avoid any issues with data integrity and power failure. – Clifford Mar 24 '22 at 21:09
1 Answers
Not familiar with the part but looking at the reference manual, the on-chip RAM is static meaning that it will retain its value so long as the power supply is maintained - even in sleep modes or through a reset. You would need to set-up the link map and start-up code to avoid initialising the reserved area on start-up.
Alternatively, the 256K flash memory is divided into 4K erase-block pages, you could reserve an entire page (i.e. set the link map to avoid locating code there). The flash endurance is only 10000 erase cycles, but even if you erases the block every two days, it would last >54 years. Since you are writing a data block of only 64 bytes you could write the blocks sequentially through the 4K such that the highest addressed non-blank block of 64 bytes is the current data; then you need only erase the page once it is entirely full, extending the endurance to 3500 years.
Note however that the flash as some restrictions:
- It must be written in 32 bit words
- A 32-bit word can only be written twice before it must be erased for be writable again.
That is to say you can write say 0xFFFFFF00, then 0xFFFF00FF, and the word would then contain 0xFFFF0000, but you could not then write the upper two bytes of that word.
Another issue with using the Code Flash is that while erasing, the bus stalls and instructions cannot be fetched. That means your code stops running. This scan be a serious issue in real-time systems; but given that your system sleeps for 3 hours at a time, presumably there are no critical micro-second level timing deadlines?
Another possibility offered by part is the UICR (User information configuration registers), a special area of non-volatile memory that includes 32 words (128 bytes) of customer defined data. However that is perhaps not very practical for dynamic storage since the area contains Nordic reserved words and device configuration, and like regular flash memory an erase deleted the entire UICR, so you would necessarily copy the data before erase and rewrite it. Not really power fail safe. The endurance is still 10000 erase cycles, if you striped it like above, having only 128 bytes would extend the endurance to 20000 cycles or 109 years erasing every 4 days.
Beyond those possibilities an off-chip NV memory device such as an EEPROM, FRAM, Flash, or even and SD/MMC card (with a filesystem). These can be attached via one of the available SPI, I2C (TWI) or QSPI interfaces. Whist likely to have higher endurance than the on-chip flah, that may still be a consideration for some devices. FRAM has no endurance issues, and SD cards are so capacious that it is unlikely to be an issue in the application described.

- 88,407
- 13
- 85
- 165
-
@Khalil, Actually, when you also want to store some other settings/configurations/parameters or failure memory, which the user might change at runtime, you would reserve 2 pages of the internal Flash. You just add to the first page until its full, then switch to the other and copy all the latest valid blocks over to the second page, in order to erase the first page afterwards. If the second page is full, you switch back to the first page. – kesselhaus Mar 25 '22 at 01:33