Flash cache invalidate.

[anatolyodler]

Hi,

I'm developing for the K10 MCU, CD IDE 10.4, compiler GCC 4.7.3.

The MCU has one block of the Flash program memory, 512Kb overall, no EEPROM.

I have written a flash driver, which provides standard services, like read, write, erase sector, to the main application.

All these routines of the driver run from RAM. The driver was implemented according to the MK10DN512VMC10(R) reference manual,

all the flash commands and register operating code is similar to the C90TFS driver available from Freescale.

The additional thing I do in my writeLongWord() routine is verifying if the data has been written as expected by simply comparing the argument of value to be written

to the content on flash taken from the argument of destination address.

What I get is these two values aren't equal somehow, while the FTFL_FSTAT register indicates no errors.

The MCU's reference manual, 28.6 Initialization and application information, tells there's a need to invalidate flash cache by writing the PFB0CR[CINV_WAY] bits

of the Flash Memory Controller. I have added this operation to my sequence before each write, it solves the verification issue.

I'm using the security of the device by configuring the security FSEC bit and the backdoor key.

I'm trying to write something on flash, which is the part of a calibration process of the device I'm developing, and then I want to unsecure the device

by the backdoor key. The issue is that, when I try to unsecure the device by applying the key, the MCU resets with no response to the verify backdoor command.

The strange thing is, if I remove the invalidating sequence of the flash cache from the flash driver code and ignore the data verification, the unsecure command works properly!!!

My conclusion is that the invalidating the flash somehow affects the security commands of the flash module.

The strangest thing is, if I write the flash, reset the MCU by hard reset (voltage switch), and then try to unsecure it, it resets as well !!!!

What does really the invalidate command do? When I need to perform it (if ever)? How can I ensure the verification of the written data succeeds?

How the backdoor verify is affected by flash cache invalidation?

Please refer to the mentioned problems.

Thank you, Anatoly.

[melissa_hunter]

Hi Anatoly,

The cache invalidation in the FMC just invalidates the small cache that resides within the flash memory controller. The FMC block is only used for read accesses to the flash. All writes and other commands to the flash go through a completely different interface (the FTFx_FCCOBn registers). Because writes go through a completely different mechanism, the FMC has no way of knowing when the flash has been modified. So when you erase or write the flash, you should invalidate the FMC cache to ensure that all future reads return the correct data instead of stale data from the cache.

Unlocking the flash using the backdoor key doesn't modify the flash contents, and invalidating the FMC flash doesn't directly impact the flash array either, so the behavior you are seeing is strange. My guess is that the cache invalidation is somehow interfering with the backdoor unlock code sequence, but it is unclear how. From a hardware perspective there isn't a link, so it is most likely something about the software itself.

You said that your driver executes flash commands from RAM. Is this also true for the verify backdoor key command? The P-flash block is not accessible while the verify backdoor key command is running. Could be that if you aren't invalidating the cache, reads from the flash are being serviced from the FMC cache instead of the flash array itself which allows the command to complete. That is the most logical explanation I can think of for what you are seeing. If this doesn't seem to be what is happening, could you provide more details on the software sequence you are using to execute the verify backdoor key command?

Hope this helps,

Melissa

[alejandrolozan1]

Hi Anatoly,

Let me work on this. It is a weird behavior.

I will get back to you as soon as I get something helpful.

Regards,

Alejandro