This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Writing to nvram

I would like help in understanding the limitations of the NVRAM. The documentation for the nRF52840 and the nRF52832 are different. This is what the nRF52840 reads:

Nvram write 52840 doc

Do I understand correctly that, for any word in a 4K block, it can only be written twice before the entire page must be erased?

The nRF52832 seems to have a different limitation:

nvram writing nRF52840

This is more complicated. Here the page is divided into 512 byte blocks and the limitations is 181 writes per block before page erase is needed. Here nothing is said about a 32 bit word write.

The reason I ask is that I am using Gazell pairing. It seems to me that, for part of the database in nvram, it partitions up its information into 4bit chunks, 8 to a 32 bit word. It shuffles bits and requires a byte to be written, I think for each pairing, which of course turns into a 32 bit word being written per byte demanded i.e. potentially 8 times. It would appear therefore that the nRF52840 is incompatible with the current version of Gazell, which, to say the least is worrying to me since I am sort-of committed to both. What is wrong with my understanding above?

Parents
  • It would seem that my initial concerns were valid. The state of Gazell pairing, even in SDK version 17, is that it uses the nrf version of write to nvram which breaks the constraints of the nRF52840 device. On the other hand, despite not liking to patch Nordic supplied software for my project, changing the nrf_gzp*.* software from using nrf_nvmc.h to use nrfx_nvmc.h was not complicated, if a little tedious, since the function names have changed. The nrfx versions are totally re-written and, whilst not completely optimal (they can still try to write 0 multiple times), they do not do that for the whole 32bit word AFAIK, just for a written byte. Since the byte only gets written twice in gazell, that is within the constraints outlined for the nRF52840. So far the re-written routines seem to permit gazell to function properly although I have only tested it for my own project.

    So, to be honourable, Nordic ought to warn users implementing Gazell on nRF52840 (this report not being in the public domain) that they must change the Nordic software as I have done.

    In addition you really should update the Gazell software to use the nrfx versions of nvmc routines and publish that in the next SDK update.

    I am now sufficiently confident in the outcome of this enquiry. Thank you very much for your assistance. The case can be closed.

Reply
  • It would seem that my initial concerns were valid. The state of Gazell pairing, even in SDK version 17, is that it uses the nrf version of write to nvram which breaks the constraints of the nRF52840 device. On the other hand, despite not liking to patch Nordic supplied software for my project, changing the nrf_gzp*.* software from using nrf_nvmc.h to use nrfx_nvmc.h was not complicated, if a little tedious, since the function names have changed. The nrfx versions are totally re-written and, whilst not completely optimal (they can still try to write 0 multiple times), they do not do that for the whole 32bit word AFAIK, just for a written byte. Since the byte only gets written twice in gazell, that is within the constraints outlined for the nRF52840. So far the re-written routines seem to permit gazell to function properly although I have only tested it for my own project.

    So, to be honourable, Nordic ought to warn users implementing Gazell on nRF52840 (this report not being in the public domain) that they must change the Nordic software as I have done.

    In addition you really should update the Gazell software to use the nrfx versions of nvmc routines and publish that in the next SDK update.

    I am now sufficiently confident in the outcome of this enquiry. Thank you very much for your assistance. The case can be closed.

Children
No Data
Related