This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

RM48 CRC module help about flash abort

uint64 crcCalculate (uint64 * startAddr, uint32 count64)
{
	uint32 count = 0u;

	CRC_CTRL0 |= 0x00000001U; /* Reset the CRC Module */
	CRC_CTRL0 &= 0xFFFFFFFEU;
	CRC_CTRL2 |= 0x00000003U; /* Configure to Full CPU Mode */

	for (count=0u; count < count64; count++) {
		/*SAFETYMCUSW 45 D MR:21.1 <APPROVED> "Reason - value 0 for start address is valid as
		 * it is used for crc calculation"*/
		CRC_SIGREG = *startAddr;
		/*SAFETYMCUSW 45 D MR:21.1 <APPROVED> "Reason - value 0 for start address is valid as
		 * it is used for crc calculation"*/
		startAddr++;
	}
    return(CRC_SIGREG);
}

I used this function to use the CRC in RM48, but I invoked this function like this

crcAtInit_FLASH = crcCalculate(((uint64 *)0x00000000), 0x2000);
crcAtInit_FEE = crcCalculate(((uint64 *)0xF0200000), 0x2000);

And the FEE one was OK but the FLASH go to a flash abort.

If I want to CRC the Flash, how to use the full_cpu_mode correctly ?

  • This is the program I used for testing CRC4705.Selftest_1.rar

  • It appears that there may be a real ECC error in this code - I'll need to figure out where.


    Ok I think this one is easy.  

    If you run your program, and get into the crcCalculate() loop you'll see that the loop starts out ok.

    But you are checking for 8192 * 8 bytes = 64K bytes. 

    I can open a memory window at address 0x8000 though (32K bytes) and see that ECC errors are there because instead of 0xFFFFFFFF

    you see:

    FFFFFFFF FFFFFFFF ???????? ???????? ???????? ???????? ???????? FFFEFFFF ???????? ???????? ????????
    FFFBFFFF ???????? FF7FFFFF ???????? ???????? ???????? ???????? ???????? FFEFFFFF ???????? FFDFFFFF
    ???????? ???????? ???????? ???????? ???????? ???????? ???????? ???????? ???????? FFFDFFFF ????????
    ???????? ???????? FFDFFFFF ???????? FFEFFFFF ???????? ???????? ???????? FFFDFFFF ???????? ????????

    Which looks like this because ECC has been turned on, but this sector of the flash is left in the erased state.
    In the erased state there are ECC errors because both the flash and the ECC syndrome are 1's and all 1's isn't valid in most cases. The only reason it's occasionally valid or occasionally can be corrected is because the address bus is included in the ECC equation, so you see different results at different addresses.

    We actually say somewhere in our documentation (I think TRM) that you need to program the entire flash if you are going to turn on ECC.

    This is because the CPU may speculatively fetch from areas of the flash that you don't have programmed.    

    So what you need to do is put a FILL construct in the linker command file so the entire memory get's programmed with something. 
    That will take care of the ECC at the same time.