3137 differences between Auto ECC and nowECC

It's likely an alignment issue & fill;  nowECC and Auto-Generate ECC on load make different assumptions about alignment in case a section is not aligned to a 64-byte boundary.   ECC gets calculated on 64-byte boundaries, so that's where the alignment comes from.   Fill is the assumption about what the unspecified contents contain.

You can confirm this by looking for the corresponding section in your .map file to see if there are any sections that are not aligned to 8 byte boundaries.

If you are always going to use nowECC to generate the ECC data and you are not going to use Auto-Generate ECC when programming or loading then you should be ok as is.   (It's the auto-generate ECC algo that gets messed up by the misalignment).

However, you can add a 'palign(8)' attribute to all your sections that map to flash in your linker command file to force alignment.  

For example:

SECTIONS
{
    .intvecs : {} > VECTORS
    .text    : {} > FLASH0 | FLASH1

 ...
}

Would become:

SECTIONS
{
    .intvecs : palign(8) {} > VECTORS
    .text    : palign(8) {} > FLASH0 | FLASH1

...
} 

Hi Anthony,

I am already using palign(8) and fill = 0xffffffff on all sections in my linker command file. I am planning on always using nowECC to generate the ECC data, unfortunatley this is the version that is giving me problems with ECC errors (data aborts) at runtime. I am appending the ecc data to my original .out file, then loading the appended file, could that cause any of these issues?

Hi Jeremy,

How are you appending the .out file - with a tool or just through a shell command?

I am appending with the '-a' parameter of nowECC.

Hmm.  Everything looks ok.  Would it be possible to see your linker .map file and perhaps the .out file that you are using as an input to the nowECC program. ?

There is a -d command line option to:

   -d                                 To ignore data lying in invalid memory
                                      regions

You might try adding this just to see what happens.

I was able to get it working by removing the alignment and fill parameters in my linker command file when using nowECC.

The only issue I am seeing now is that after running for a while with Flash ECC enabled, my error light comes on (ESM->ErrPinStat goes low). Inspecting ESM shows Status Register 3 = 0x00000080. I think I read somewhere that getting a prefetch to a bad ECC location can cause this even though the prefetched address is never actually accessed. Is there a solution for this?

Jeremy,

Wow that is counter-intuitive;  it seems like this is doing the opposite of what it's supposed to.
We'll need to understand this more by talking to the development team.

I think regarding the ESM error you are probably thinking of this section of the TRM:

Which would indicate that you should fill the remainder of the flash adn generate correct ECC for the fill.  I hope this doesn't undo the fix that you've gotten to above.   If it does you might try removing the -le option (a hunch).

Anthony,

I have added the fill = 0xffffffff {} option to each flash section in my linker cmd file

I have the following flash ranges defined in the linker cmd:

BTAPITBL (R) : origin = 0x00008000, length = 0x000060

BTCNFTBL (R) : origin = 0x00008060, length = 0x000100

BTVERTBL (R) : origin = 0x00008160, length = 0x000010

BTROM    (R) : origin = 0x00008170, length = 0x004000

Here is an example of a line from my Sections definition:

BTAPITBLSEC    : fill = 0xffffffff {} > BTAPITBL

However in nowECC, ECC values are only generated for addresses where actual vaules exist (not filled areas).

Here is the nowECC output:

ECC calculation from 0x00000000 to 0x0000001F

ECC calculation from 0x00008000 to 0x00008057

ECC calculation from 0x00008060 to 0x0000814F

ECC calculation from 0x00008170 to 0x0000AE17

It's as if the fill parameter has no effect or nowECC is ignoring it.

In this example I am not filling all of flash, I am only trying ot fill a small area. I have multiple loadables (about 5) that will need to be exapanded and filled in order to meet the requirement for ECC values for all of flash.