Hard Faults reading program Flash memory

[ryanmonfils]

I have custom firmware consisting of a Bootloader and application on the Kinetis K22FN1M0VLL12.  My Bootloader goes through the following sequence. 

1) Send a command to erase enough Flash to program the new application.

2) Send the application in packets via the UART.  Write each packet into Flash as it comes in.

3) Reboot

4) Compute a CRC over the entire application in Flash and compare against a pre-calculated value.

5) If the CRCs match, jump to the application.

I don't believe I'm doing anything unusual.  I've been testing with corrupt application images to ensure that the system recovers properly and have discovered an issue.  Sometimes after an update while looping through the CRC calculation, I will jump into a Hard Fault.  I can't understand why this is happening and am not sure what to try next.  The Hard Fault seems to coincide with the portion of the application I corrupted but it shouldn't matter since I am just reading the Flash location.  Any suggestions?  Below is the snippet of CRC code.

uint16_t calulate16BitCrc (uint32_t startAddress, uint32_t length)
{
    volatile char* dataPtr;
    char newData;
    uint16_t crc;
    dataPtr = (uint8_t*)startAddress;
    crc = 0x5555;
    for (int i = 0; i < length; i++)
    {
        newData = *dataPtr;
        crc ^= newData;
        crc &= 0xFFFF;
        crc = (crc >> 15) | (crc << 1);
        dataPtr++;
    }
    return crc;
}

[bobpaddock]

I'll leave the flash read part to others.

Your CRC looks suspicious.

A 16-bit CRC is only good for 4K minus 1 bit of data for the mathematical properties to apply.
The initialization  0x5555 is not one of the standard ones.  The standard ones have been selected so that the math properties do apply, so that leading and trailing zeros or ones don't cause issues.

For all but very small parts, those less than 4K a 32 bit CRC should be used.

Reversing CRC – Theory and Practice. 

http://stigge.org/martin/pub/SAR-PR-2006-05.pdf 

CRC primer by Ross Williams 

I've spent far to much time reading books on syndrome lengths of Galois fields and such.  Just wish someone with a math background would write the CRC Handbook that says 'this one does that for data block of size X'... :-(

[egoodii]

True enough in general.  However, due to the 'other features' of the flash system which are causing these hard-faults, the CRC operation is, in fact, relatively superfluous.  The chances of IT catching an error from a 'faulty-flash-read' that did NOT 'kill the loop' on such in a hard-fault is downright negligible.

[rastislav_pavlanin]

Hi,

I would also recommend to read Configurable Fault Status Register (CFSR) defined in System Control Space (SCS->CFSR) of the core registers. From this status you can get more information what could potetialy cause the hardfault.

If CM0+ usage I would expect unaligned memory access occurred during code execution.

However, the same can happend on CM4 (which allow unaligned accesses) if UNALIGN_TRP bit in Configuration and Control Register (CCR) is set to 1. In such case when unaligned memory access occur Unaligned access UsageFault will be generated. If USGFAULTENA in System Handler Control and State Register (SHCSR) is set to 0, then usage fault exception is disabled and hard fault is generated instead of.

regards

R.

[ryanmonfils]

Ok.  So why would creating a pointer to a memory location and reading consecutive Flash values generate a hard fault?

[egoodii]

Sorry, the details are not for a public forum.  Email me at goodrich@lectronix.biz

There is nothing wrong with your code, the issue goes deeper than that. CFSR and/or DFSR MAY give a 'hint'.  I can tell you exactly what is going on.

[egoodii]

For a little information on this 'poorly held secret', I can also refer you to:

https://community.nxp.com/message/439645?commentID=439645#comment-439645

[egoodii]

Most 'flash read errors' will generate a hard fault.  Email me if you want details.