SPI Flash Logging

[hellopic]

I've an application where the PIC acts as a FIFO across two UART ports. The data comes in at constant rate from 1 UART, the data is stored on SPI flash (which is connected to the PIC) and then when the 2 UART asks for it, send it out.

The problem is that the FIFO must work across power-cycles, meaning I need to maintain FIFO counter information across loss of power. My options are:

1) Write the FIFO counter information to the SPI Flash whenever a packet is written. This will be limited by the number erase/write cycles for the SPI flash, which are around 100k.
2) On power-up walk through the SPI flash to re-build the FIFO information. This is what I am currently doing but sometimes, the SPI pages would come up as blank even though there is data on it (Not sure why). So this has to be supplemented with some other technique.
3) The flash will let me write partial words of a page - i.e. in a 4k page, I can fill in as I wish but will this have any affect on the endurance and such?

Any advice? Thanks.
The PIC is a dspic33 chip and it doesn't have any on-chip or off-chip EEPROM. Just SPI flash - SST25VF016B

[Ttelmah]

4) Add a large external capacitor (you may be surprised at how small this can be, and a way of detecting the power going off. Have this trigger an interrupt, and have this write the required data....

This is a fairly standard way of doing this.
Alternative:
5) Change to FRAM instead of flash. This way no write cycle limit, and much faster writes.

Best Wishes

[hellopic]

Thanks for the suggestions, Ttelmah,

The hardware is fixed, unfortunately.

I am thinking, I reserve a few pages in the flash and then start writing counter values sequentially to it. So that I don't have to erase so often. Is this a normal way? I was looking at flash filesystems such as Keil's RL where they write file allocation information as and when it happens to the same block. So partial writes probably don't have as much affect as they do in NAND flash?

Also, any idea why a read from SPI flash might arbitrarily show up as blank? Thanks very much.

[gpsmikey]

Sometimes showing as blank sort of hints at a timing issue. The key question is if you run into that condition, does multiple reads of the same page return the same (blank) data or does it sometimes work and sometimes not for the same page (which would point to a possible timing issue) ? If it always returns blank when it gets in that mode, then I would suspect something on that page that your code is seeing as data, if it is a "sometimes" thing (when the data has not changed in the FLASH), then I would suspect a timing issue.

mikey
_________________
mikey
-- you can't have too many gadgets or too much disk space !
old engineering saying: 1+1 = 3 for sufficiently large values of 1 or small values of 3

[Ttelmah]

The common way of reducing cycles, is to remember that it isn't a write that uses a cycle, but an erase. Once a page is erased, on most memories you can write 'non erase' values to a single byte or a couple of bytes without using a cycle. Normally the erased value is 0xFF, so you reserve this value as 'cell is available to use', and then store numbers using hex for example, in blocks of (say) four bytes, writing four bytes to the next group that does not contain 0xFF, and then setting the last group to zero to say that there is now a newer value. With a 4K page (this depends on the chip), you can then write 1000 4 byte numbers for one erase cycle.
Use a couple of pages, and when you transfer to the second page, erase the first. This way the active page is the one starting with non 0xFF values.
Obviously, since you can't store a value of 0xFF, and the 00 value is treated as a 'used' flag, you have to avoid these values in what you store. Hex is a simple way of avoiding these.

On FRAM, there are direct replacements for many of the SPI EEPROM's, so no board change might be needed. Worth still considering if this is the case.

Best Wishes

[barbiani]

I think that FRAM are a great idea... if addressmod works for you, then you will not need to care about writing the data manually. Just treat the FRAM as internal RAM.

[hellopic]

Thanks for all the suggestions, guys.

I went with an Index page that sets a value when a corresponding block/page is written. Working well so far.

I looked at FRAMs but they seem pretty expensive but probably worth the money. Will keep them as an option for future projects. Thanks.