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.

RM57L843: Bank 7 Programming - Fapi_doVerify failing in certain cases.

Part Number: RM57L843

Hi,

I've posted on this topic a year ago, I though it was solved, but its back.

The symptom is defined such that: I can write a buffer stored in RAM to FLASH Bank 7 using the Fapi. After the write is complete, if I manually verify the FLASH contents by simple word-wise comparison, or use Fapi_doVerify, I get an verification failure and I also notice that the memory browser is not updated to reflect the values that should be written to FLASH.  However when I reset the target, Bank 7 shows that it was written correctly and can be verified as successful.

Here is the approximate pseudo-code:

1. Reset target

2. Init the FLASH, etc.

3. Read 4096 bytes from flash at 0xF020000 into RAM at 0x08007800 (yes its aligned)

4. In this example the value at 0xF0200000 is 0xAABB1235.

5. The RAM buffer at 0x08007800 also shows 0xAABB1235 in the memory browser.

6. Modify 0x08007800 from 0xAABB1235 to 0xAABB1234

7.Reprogram the entire buffer, 8 bytes at a time using Fapi_issueProgrammingCommand

8.After each 8 bytes wait for Fapi_checkFsmForReady and ensure the return code from the command is Fapi_Status_Success

9. After all 4096 bytes have been programmed, call Fapi_doVerify, which returns a Fapi_Error_Fail. I also call Fapi_flushPipeline before any reads. Please note that the status from Fapi_doVerify shows a failure at exactly the address with exactly the data in the above steps. It is clear from this that even Fapi is reading stale data.

10. Check in Memory browser, FLASH is not updated.

11. Reset target (Just a simple CPU Reset from CCS)

12. Check memory browser and 0xF0200000 shows 0xAABB1234, this indicates that the FLASH was written correctly!.

13. Fapi_doVerify returns success now, (without another programming attempt).

I need to know what I'm doing wrong. This seriously looks like some sort of cache coherency problem, where the FLASH read by the RM57 appear to be stale cached values prior to FLASH write.

We use this same FLASH driver, with some small #define differences on RM48, and have so for about 5 years now, without any recorded faults in testing.

Can anyone please suggest anything I need to look at?

Thanks

Stomp!

  • Hi,

    I will get with the flash API team and get back to you ASAP.

    Regards,

    Sunil

  • Hi Stomp,

    The flash API expert suggested that accesses to the data flash bank must not be cached. Writes to the FEE bank are done using a state machine and bypasses the CPU's interconnect, so there is no way for the cache coherency logic to identify that any cache contents are invalid. You can define the FEE bank as device-type or strongly-ordered memory by configuring the CPU's MPU. This will prevent reads from this data flash bank from being cached.

    Regards,
    Sunil

  • Thanks again Sunil,

    I suspect its a MPU setting issue on my side, I'll go and review.

    Appreciate your time in getting back to me.

    Thanks

    Stomp!