NV circular history logging on CC2540

In addition to what LPRF has indicated.  My experience is with vehicle odometers where both requirements must be met; not to exceed the EEPROM NV write cycles and not to lose mileage data. We manage the data on RAM initially, and periodically write this data at a lower cycles on EEPROM and before going into sleep or completely off-power.  Now, this poses another problem; anytime you have data being caches on RAM and EEPROM, there is the need to perform some redundency checks with segment checksum. Not knowning much about your problem and timing; here are the steps I would apply;

(1) Find out the worst case for fastest & slowest incoming of your data. (2) Is your device going into complete sleep between data logging? (3) Is this sleep using power mode where RAM is unpredictable? (4) Is your data needs to be timestamped? (5) Do you care only about different data or do you have to log same data.

Once you have these answer; you would want to keep your data on RAM as "reasonable" as possible and cach it on EEPROM at periodic rate or some event (example; before going to sleep). The "reasonable" is depending on how much data loss you can tolerate? ie. if every message needs to be logged; then you have no choice. But if you can filter duplicate data out with some time-stamp/ count then you can do some pretty good design.

Hope this helps

In the overall scheme the frequency and number of flash entries will not be very high.  Guestimate two to ten times per day.  A User-caused event is to be logged with its osal_clock timestamp, a one-byte event code and an 11-byte event data block.  This will be written to flash and the requisite index is advanced in anticipation of the next record.  The log will cover multiple flash pages so that when the index crosses into a new page and the first record of that page is not clear (all 0xFFFFFFFFs), the page gets erased.  This is a circular buffer (FIFO) with 128 records per flash page.  I expect to have perhaps 16 pages available.

I have been able to write and read the first word of the first record (the timestamp) but the remaining three words are not as expected when read.  This brings up the question of how to get the IAR debugger to display arbitrary areas of flash.  I would like to have a look at the area I believe I am writing to.  So phrase it in the form of a question, how can I look at the 64-128 bytes around the location where my buffer is supposed to start?

What you're trying to do is fairly straight-forward, but requires a very good understanding of the 8051's bank switching architecture.  In particular, you need to understand the mapping of memory addresses to flash bank addresses.  Some suggestions:

- Read sections 2.2 (memory) and section 6 (flash controller) in the 2540 user's guide (SWRU191C), esp section 6.2.2 Writing Multiple Times to a Word

- Use TI's NV implementation as an example (osal_snv.c)

- The linker command file is also involved, search for BLENV_ADDRESS_SPACE in the linker command file (.xcl) and grok how it relates to its usage in osal_snv.c.

You can view flash memory directly with IAR debugger by poking the appropriate values into the memory mapping register(s).

The above is all based on experience with the v1.2 stack, not sure if v1.3 is different.

This is good information, thank you.  I have downloaded but not installed 1.3 (yet).

The multi write issue should not be a problem as each record is 16 bytes (4 flash words) and is written as a whole and then the index for the next write moves to the next record.  Overwrite is prevented by using multiple pages and examining the record to be written for blank (all FF's) if not blank the page is erased prior to writing the record.

I am hesitant to close this question until it's proven working, but I have: a) found the area in flash I need; b) actually written data; c) read data back, but only the first word is correct, the other three are not.  Do you know how to get IAR's debugger to view the flash at my page number?

You can view flash memory directly with IAR debugger by poking the appropriate values into the memory mapping register(s).  Its been a while, so I don't remember exactly which register.