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

Is it possible to continuously log data to flash memory?

I'm not sure if this question has been asked here before, but I couldnt find an existing answer...

I know that flash memory only has a relatively limited number of write / erase cycles.

For the nRF51 this is 20,000.

But from what I understand, this number is for the erase command to a page of flash.

So it may be possible to log to flash, by writing to the next available empty address, rather than erasing an overwriting an existing value.

Hence the number of log values that can be written is governed by the size of a flash page, and the number of available pages in flash (not used for the Application)

Is there any existing example code which does this sort of thing? As I think that data logging is a common requirement.

Parents
  • I know this is a common problem, so I will see if I can find a generic solution, and write code to use that solution using the API which controls writing and erasing of flash.

    e.g. If an erased location reads back as 0xff I can use this to find the next available location after the code starts, then after that store the location of that address in RAM.

    I just need to make sure that the data struct I am writing, cant contain 0xff in the first byte, or perhaps cant contain 0xff for all bytes. i dont think it would be a big problem to ensure that the whole struct was not 0xff

Reply
  • I know this is a common problem, so I will see if I can find a generic solution, and write code to use that solution using the API which controls writing and erasing of flash.

    e.g. If an erased location reads back as 0xff I can use this to find the next available location after the code starts, then after that store the location of that address in RAM.

    I just need to make sure that the data struct I am writing, cant contain 0xff in the first byte, or perhaps cant contain 0xff for all bytes. i dont think it would be a big problem to ensure that the whole struct was not 0xff

Children
No Data
Related