Is it possible to continuously log data to flash memory?

RE: Is it possible to continuously log data to flash memory?

awneil — Sun, 19 Feb 2017 17:15:08 GMT

Yes, using bits is a common approach

RE: Is it possible to continuously log data to flash memory?

Roger Clark — Sun, 19 Feb 2017 00:28:32 GMT

I don't think my data can ever be zero for the entire block I'm writing, so an allocation table wouldn't be necessary in this case, and would use up space into which I could log data.

BTW. If I did want to use an allocation table.. Is this done by using individual bits in each byte, otherwise if the chunks of data (struct) I'm writing was fairly small, (which it may initially be), the space taken by the allocation table could be significant.

RE: Is it possible to continuously log data to flash memory?

awneil — Thu, 16 Feb 2017 07:29:57 GMT

Rather than restrict the data to not contain (all) FF, a common approach is to have an "allocation table" which shows what blocks have been used -so you just scan through the table to find the next "free" block...

RE: Is it possible to continuously log data to flash memory?

Roger Clark — Wed, 15 Feb 2017 22:28:25 GMT

BTW

Looking at the spec for the nRF51 it looks like the Flash page size is 1024 bytes.

If so thats quite good as it will not loose a large chunk of the circular buffer when I clear a page.

RE: Is it possible to continuously log data to flash memory?

Roger Clark — Wed, 15 Feb 2017 20:35:52 GMT

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

RE: Is it possible to continuously log data to flash memory?

Roger Clark — Wed, 15 Feb 2017 20:30:25 GMT

Thanks.

I looked at the low level API, and could use that, with a suitable page erase strategy.

I think after a page of flash is erased the values read back as 0xff, so I should be able to use that as an indicator of the next available location, as long as the first byte in my data struct can never be 0xff

RE: Is it possible to continuously log data to flash memory?

awneil — Wed, 15 Feb 2017 13:21:02 GMT

Yes, it is true that the thing which "wears" Flash (any Flash) is the erase.

So it is quite common to have a method along the lines you suggest; you might have a table - like the File Allocation Table in the FAT disk format - which shows where the next "free" space it; and, instead of actually erasing an entry, you just mark it as "deleted" ...

RE: Is it possible to continuously log data to flash memory?

bjorn-spockeli — Wed, 15 Feb 2017 11:59:35 GMT

Yes, then I agree that the FDS module might not be the best fit. I think it might be better to look at the fstorage library instead that is used by the FDS library to perform the actual flash operations.

RE: Is it possible to continuously log data to flash memory?

Roger Clark — Wed, 15 Feb 2017 11:57:13 GMT

Thanks

I have used the FDS, but only for small structs of data, containning settings used by the application.

I need to log an 8 byte struct once per minute, so that the total storage will be a circular buffer of 8000 samples.

And FDS didnt look like it was designed for this sort if operation.

Howver I will analyse the examples on github and see if anything looks like my uze case,

RE: Is it possible to continuously log data to flash memory?

bjorn-spockeli — Wed, 15 Feb 2017 10:42:26 GMT

Hi Roger,

I think that the Flash Data Storage(FDS) library covers the use-case that you're describing. The library is described on this page on our Infocenter.

There are some examples on our GitHub site, found here. They are, however, based on SKD v11.0.0, but it should not be a big task to port them to the latest and greatest SDK v12.2.0.

Best regards

Bjørn