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
  • Oh, oh, Am I misleading people here. I have just discovered that there are TWO versions of write to nvram and I am probably looking at the wrong one. The one that I have been analysing is nrf_nvmc_write_byte which is included in my project. It is still extant in sdk V17 and is one of only two .c program in the .hal subdirectory under "nrfx". I have just found a version which is nrfx_nvmc_write_byte which is much more generic and, at first glance, looks like it doesn't have the same problem. That is in 

    nRF5_SDK_17.0.0_9d13099\modules\nrfx\drivers\src

    I wish that someone had mentioned that I was using out-of date software as from SDK V16 - would have saved me some time. Also, how are users supposed to know when they can change from nrf to nrfx versions? I obviously missed something.

    So, I think I will close the case after a bit of study of how the nrfx version works simply with the remark that "If you continue to use the nrf versions on the nRF52840, you will be contravening the hardware limitations. Switch to those in nRF5_SDK_17.0.0_9d13099\modules\nrfx\drivers to avoid that". Sigh.

    (edit) not so fast - being as the name is changed the software for gzp no longer links. I will have to look at how the old and new match and maybe edit gzp software which I am not too keen on. - more later.

Reply
  • Oh, oh, Am I misleading people here. I have just discovered that there are TWO versions of write to nvram and I am probably looking at the wrong one. The one that I have been analysing is nrf_nvmc_write_byte which is included in my project. It is still extant in sdk V17 and is one of only two .c program in the .hal subdirectory under "nrfx". I have just found a version which is nrfx_nvmc_write_byte which is much more generic and, at first glance, looks like it doesn't have the same problem. That is in 

    nRF5_SDK_17.0.0_9d13099\modules\nrfx\drivers\src

    I wish that someone had mentioned that I was using out-of date software as from SDK V16 - would have saved me some time. Also, how are users supposed to know when they can change from nrf to nrfx versions? I obviously missed something.

    So, I think I will close the case after a bit of study of how the nrfx version works simply with the remark that "If you continue to use the nrf versions on the nRF52840, you will be contravening the hardware limitations. Switch to those in nRF5_SDK_17.0.0_9d13099\modules\nrfx\drivers to avoid that". Sigh.

    (edit) not so fast - being as the name is changed the software for gzp no longer links. I will have to look at how the old and new match and maybe edit gzp software which I am not too keen on. - more later.

Children
No Data
Related