Flash ECC error when using compiler optimization

Aedu,

Does this code work when compiled without -o3?

Thanks and regards,

Zhaohong

Zhaohong

Yes, the code works without  -O3 (debug configuration). The Flash ECC selftest passes.

Regards
Aedu

Aedu,

Would you please check if the global pointer "flashWREG" is defined as a volatile type?

Thanks and regards,

Zhaohong

Zhaohong,
The global pointer "flashWREG" is defined like this:

typedef volatile struct flashWBase
{
 ...
} flashWBASE_t;

#define flashWREG ((flashWBASE_t *)(0xFFF87000U))

That looks ok for me. Do you have any other suggestions?

Regards
Aedu

Aedu,

this seems to be an timing issue, with the code executed to fast to recognize the failure in time when optimizations are used.

I would propose to add a readback of register FDIAGCTRL in the code after enabling the diag mode:

    flashWREG->FEDACCTRL1 = 0x000A060A;            
 
    flashWREG->FDIAGCTRL = 0x00050007;            
    
    flashWREG->FPAROVR = 0x00005A01; // halcogen_mod: Halcogen Bug, 0x00005401 is wrong
    
    flashWREG->FDIAGCTRL |= 0x01000000;

        flashWREG->FDIAGCTRL; /* Read Back */
    
    flashread = flashBadECC;    
    
    flashWREG->FDIAGCTRL = 0x000A0007;   

This should ensure, that the write to the FDIAGCTRL register has been propagated trough the bus matrix before reading the "faulty" data.
I currently don't have a kit available to test this, can you please let us know if this does the trick?

Best Regards,

Christian

Aedu,

I tried this on the bench, for me this test didn't worked at all so I dug deeper into this.

The reason for me why this test always failed was, that there was no data at the flash location where the read happens and thus also no ECC data which caused an uncorrectable error instead of an correctable one.

This might also be the case for you, if you got optimizations disabled your code might be huge and there is data at this location, if you enable optimizations your code shrunk and the test fails because of an uncorrectable error (data abort).

The location where the read happens is defined as follow:

#define flashBadECC        (*(volatile uint32 *)(0x20040000U))

This is the mirrored flash image (bus 2 access).

You should eigther specify an fill value in the Linker Command File, which causes the linker to fill the unused flash memory with an pattern or you should somehow ensure that some data is placed at 0x00040000.

I would prefer the first option, because it is anyway good to fill unused flash memory and generate ECC for this, in order to avoid ECC faults during speculative fetches (prefetch abort).

Anyway if you want to place some data at a specific location you can do this with the following lines of C code:

#pragma RETAIN(forceData);
#pragma LOCATION(forceData , 0x00040000);
const uint64 forceData = 0x12345678ABCDEF12ULL;

Please let us know if this solved your problem.

Best Regards,
Christian

Christian
Thanks for your help. The problem you encountered on your test bench looks similar to mine.

I had already specified a fill value in the linker command file, nevertheless I had the the problem.

When I place some data at position 0x0004000 as you suggested, then the problem seems to be solved. The application and the flashECC selftest runs (using  -O3 optimization).

In spite of having a fill value in the linker command file, it looks for me that the flash is not filled entirley with valid data with correct ECC. I'm not yet using the nowECC as post build step, but have the Auto ECC generation enabled (in the CCS project settings). Is there something more to consider using Auto ECC generation?

Best regards
Aedu

btw: When I add  "forceData"  to the "Expressions" window in CCS, it shows me the wrong address (0x80000 instead of 0x40000). In the .map file, it is placed on the correct location.

Hello Christian
Now it works.
I specified fill values for all flash section in the SECTIONS part of the LCF, but not in MEMORY part. That was the problem.

Thanks a lot
Aedu