What is the best practice for programming a flash parameter block (for non-volatile device configuration parameters)?

Hi Adam,

I'm sorry, but I think I don't understand this question correctly!

Adam Brailove said:

The parameter block is a big C struct.  I can initialize the struct in firmware to the 'factory default' values by assigning values to each element of the struct.  This is self-documenting, and easy to read and modify.

When you're talking about 'initializing' by firmware what do you mean? After power-up i.e.?

Adam Brailove said:

The initialization section of the firmware code can then write this struct containing these hard-coded values to flash .

Why will you write some known data to flash after each power-up?

I would do it this way:

- Modify the linker control file that way that it gives a segment in the flash memory ( (i.e. named INITDATA) which is large enough to store the 'factory initialization data' (also needs to take the min. page size for a 'flash erase' = 1kbyte into account). This data is then accessed by using a 'big struct' during runtime

- a constant table - representing the initialization data - will be placed (linked) into this segment

Now, the user wants to change the data (default data). If your RAM memory is large enough you can load the whole constant table to RAM, let the application (i.e.User via terminal commands) change some of the parameters and then the application calls a functions which

 a) erases the INITDATA segment and

 b) writes new (custom) data to flash.

So, does this szenario represents what you're trying to do?

You may also want to have a look at this application note http://www.ti.com/mcu/docs/litabsmultiplefilelist.tsp?sectionId=96&tabId=1502&literatureNumber=spma030&docCategoryId=1&familyId=2940 . It covers EEPROM emulation on Stellaris MCUs.

aBUGSworstnightmare

Hi,

@aBUGSworstnightmare: I think he refers to the file utils/flash_pb.c...

Petrei 

Hi Adam,

The typical way to do this is with some sort of checksum (simple or CRC).  The FlashPBIIsValid() function does a simple checksum on the parameter block.  Your start-up code could call this function and program the default values if the function returns 0 indicating that checksum is not valid or if all values are 0xff.  A benefit of this is that if the parameter block gets corrupted, then the defaults will be restored. 

Note that the checksum here is a simple byte-wide check, so it has limitations.  A CRC-16 check would provide safer validation.

Hi Adam,

I'm sorry, but I can't provide you a proven example for Stellaris! Here's an example how I did it on a MSP430 (modified for the Stellaris .cmd-file format). In principle it's the same on the Stellaris.

1. Modify the linker command file (i.e. lm4f120h5qr.cmd for the LM4F120; the file is in your project folder by adding a new memory block and a section definition.

MEMORY

{

    FLASH (RX) : origin = 0x00000800, length = 0x00039200    

 CHANNEL0 (RX) : origin = 0x00039200, length = 0x0400

    CHANNEL1 (RX): origin = 0x00039600, length = 0x0400

    SRAM (RWX) : origin = 0x20000000, length = 0x00008000

}

This example will define 2 segemts in flash (CHANNEL0 and 1; located at the end of the available flash memory), each 1024bytes (0x400) large. You need to reduce the ammount of available flash (segment FLASH) respectivly (was 0x40000 --> now 0x39200) 

Now, you need to add a new section (scroll down in the .cmd file):

/* Section allocation in memory */

SECTIONS

{

    .intvecs:   > 0x00000000

    .text   :   > FLASH

    .const  :   > FLASH

    .cinit  :   > FLASH

    .pinit  :   > FLASH

    .channel0 :  > CHANNEL0 

   .channel1 :  > CHANNEL1

    .vtable :   > 0x20000000

    .data   :   > SRAM

    .bss    :   > SRAM

    .sysmem :   > SRAM

    .stack  :   > SRAM

}

This tells the linker were to place the data in.

For details on the linker command file refer to the documentation please!

2.) Initialize your constant table and tell the linker were to place it by using a #PRAGMA directive:

#pragma DATA_SECTION (move0, ".channel0")

const unsigned int move0[53] =

          {

            16,                  // Write value to flash   --> 17 position data sets

            // number in flash needs to be actual no of positions -1

            0,

1430,

160,

50,

1060,

160,

82,

1785,

160,

50,

1200,

160,

50,

1628,

160,

67,

1200,

160,

50,

1500,

160,

71,

1375,

160,

5,

1505,

160,

43,

1120,

160,

50,

1800,

160,

30,

1718,

160,

50,

1175,

160,

172,

1761,

160,

35,

1430,

160,

12,

1245,

160,

10,

1550,

160,

50,

          };

I only used constants for this example but you can initialize (and place) your structure the same way.

A brief explaination:

#pragma DATA_SECTION (move0, ".channel0")--> we're dealing with data and not op-code, the variable 'move0' will be placed in the section '.channel0' which is located in the memory SEGMENT CHANNEL0 (Flash memory).

EDIT: You need to switch back to the default segment at the end of your definition; I think it's done by #pragma DEFAULT (but I'm not quite shure about this since I usually use a separate .c-file for each special segment).

Access to your data is as usual; nothing to care about.

aBUGSworstnightmare

Jonathan,

your suggested method is elegant and it solved the problem.  Thanks.

My code is based on the API in StellarisWare utils/flash_pb.c which handles checksum and fault tolerance etc very nicely.

So I used FlashPBGet() which according to the docs:

 "Returns the address of the most recent parameter block, or NULL if there is no valid parameter blocks in flash"

For reference, a code snippet (without error checking) is below:

--------------------------  CODE SNIPPET ------------------------------------

// ---- Flash Setup.  tFlashParams is a struct that holds all my parameters

uLen = sizeof(tFlashParams); // Get length of parameter block struct

FlashPBInit(0x3f800, 0x40000, 512);   // Set up parameter block of 512 bytes, in two erase pages starting at 0x3F800 (2 pages x 1024 byes/page)

pucParamBlock = FlashPBGet();   // Attempt to get valid flash parameter block

if(!pucParamBlock) { // If there is no valid flash parameter block then...

FlashParamsDefaultInit();   // Initialize all the variables in global struct to their default values

FlashPBSave((unsigned char*) &tFlashParams); // ...and write the struct with default values to flash

}

pucParamBlock = FlashPBGet();   // Now get the pointer to the parameter data from flash

if(pucParamBlock) {   // If valid now, then ....

memcpy(&tFlashParams, pucParamBlock, uLen);   // copy the contents of flash back into the struct

}

A couple of other items to consider along Bruno's lines

1. A version number of the structure. Lets you detect changes that leave the EE size the same but change meanings.
2. Mirroring. Parameter writes can be interrupted. Keeping a mirrored copy lets you select a backup if one is corrupted

I end up with multiple parameter block types

• Checksumed and mirrored
• Checksummed and not mirrored. These might be too large to mirror or easy to generate reasonable defaults.
• Not checksummed or mirrored (usually faults or logs)

Robert

Perhaps it should be noted that "Adam" was last seen/heard/read - these parts - more than FOUR Years past!

Hovering over his name reveals "Recent Activity" - which notes such, "Four Year absence..."

And if you are interested in the next level of abstraction. I develop the structures in a spreadsheet (one tab per block) and generate any needed code from there.

Robert

Ola Robert - that is SO GOOD that it (may) even cause "Adam" to reverse his abandonment of this forum...      (maybe)

cb1_mobile said:

Perhaps it should be noted that "Adam" was last seen/heard/read - these parts - more than FOUR Years past!

Hahaha, that's blushing! That fellow has probably given up EE and is now a resident in some hospital after so long!    :O

Alright, poster "Jordi Nonell Canals48": PLEASE, DO create a new thread if you come across a similar situation, ok? Your question/issue is not the same as the original's thread title!

When other people read a thread, there is a HUGE tendency to assume that the first post is the QUESTION, and all other are comments or further details, but not really a new completely different question.

(Or at least, I MYSELF have that huge tendency...)

Anyway, as far as your (Jordi's) question goes, I am not familiar with FlashPB library, and I suggest you use the Flash API's which are part of Tivaware. Create your own set of auxiliary functions for reading/writing your structure into flash memory using Tivaware calls.

Bruno

Bruno Saraiva said:

I don't think we ever spotted a corrupt saved structure in our products - we just rely on reading the eeprom again after writing the structure

I have and your test wouldn't catch most of them.

Consider what happens if

• You lose power part way through writing a block. Holdup may be feasible on an individual write but not necessarily for a full block
• You get a reset part way through writing.
• EMI induces a write before you write protect the EE. Note: my experience is the induced write could be anywhere.
• The non-volatile memory isn't. Yes I've seen this happen. Had to add production tests to catch the faulty devices.

One you are write protected it's pretty safe but before then there are multiple sources of interference.

Your test catches the case where the write failed or the first read after the write failed. You will only notice the other failure mechanisms because of add side effects. And if you do get the case you are checking I'd venture the odds of the others happening is high.

Robert

Note: some standards require non-volatile parameters be secured by some sort of checksum.

Bruno Saraiva said:

Good thing that all these protections can be added to the library itself (I hope), hence the application as is will still be able to simply read or write a "non-volatile" structure with no need for changes.

Seems likely. You appear to have a good setup.

Bruno Saraiva said:

I agree that none of your fault scenarios are too hard to happen - we were probably just lucky that our hardware are kind of designed in a way the those are very unlikely

Or you're unlikely enough that the failures are subtle enough that no one has attributed them to odd values in the EE :) To be fair a lot of the failures I observed were in a relatively high EMI environment.

Bruno Saraiva said:

will be moving this "non-volatile" protection implementation higher up on the (long) to-do-list.

It only gets short once support is abandoned doesn't it? :)

Robert

Bruno Saraiva said:

will be moving this "non-volatile" protection implementation higher up on the (long) to-do-list.

And - might that (long) "to-do-list" become (even) longer - as, poster "Adam" has, "(long) Fled the building..." 

Somewhere (w/in past 90 days) electronic press compared/contrasted EE memory "w/in MCUs" vs. "stand alone ICs."       Hands down - stand alone ICs won - beware!

cb1_mobile said:

compared/contrasted EE memory "w/in MCUs" vs. "stand alone ICs."

I wouldn't expect a different result. A dedicated part is usually, well, designed for the purpose.

But still it appears to me that a well implemented eeprom library can fully achieve the published/datasheet eeprom functionalities, and the scenario of not having to add/route/procure/configure one extra circuit is attractive.

I assume that almost every project that involves an M4 arm-based MCU demands some sort of non-volatile storage, and at least this basic need should be addressable without the need for external parts. Coming to think of it, I have recently looked at that other vendor's tenfold-more-popular processor, and the lack of internal eeprom was a fact that surprised me... 

Low volume NV storage? Whenever cost allows, I'm a fan of F-RAM.

Regards

Bruno

You may note that (both) friend Robert and I advise posters,  Avoid, "Premature Optimization!"       (always have to "bear down/focus" when keying in that phrase...)

All here must "note" (really note) that - as poster Bruno writes, "not having to add/route/procure/configure one extra circuit" has some appeal."    

Yet - and significantly unsaid - is the EXTRA: "Time, Effort, Testing, Verification and very real RISK" which such "saving" admits.

Perhaps better to employ KNOWN, SUPERIOR, More ROBUST external device (we too like Fram) until the "potential benefit" of such "saving" is very well established - thus proven.     (btw - that "proof" is rare - far better: SAFE, SECURE (via external device) than "Sorry" (via the MCU alone) as "kitchen sink" (Do everything - fairly poorly - at that.)

I would add that - most always - the inclusion of, "SPI Bus and SPI ICs" avoids or at least minimizes "added" routing demands - and in fact is "Standard Practice" w/in our firm!       (we may chose "DNF" (Do Not Fill) should the fram not be required - yet its footprint & routing are ALWAYS there!         (thus ALL (earlier) objections to SAFE/SECURE/EXTERNAL Device dissolve...)