K20 and K60 vs flash erase and most likely cache

[a_r_f_]

Dear NXP,

I'm developing a firmware which is supposed to store some data in internal flash. The target hardware used by the customer is based on MK20DN512ZVMD10, while for development I have your tower system with MK60DN512VMD10. We both have a recent MCUXpresso and SDK for K20.
I expected that these two microcontrollers would be compatible, but there are some differences in their operation regarding flash. Could you, please, help me with that?

1) Erasing flash
a) On my K60 the function fsl_flash_erase works fine, but on the target K20 it causes a reset.

b) We've also tried a "custom" erase function according to the description in the manual. In pseudocode it goes like this:

wait for completion of previous operation (CCIF -> 0)
delay (for loop)

clear ACCERR and FPVIOL fields - just in case

load values to FCCOBx registers

set CCIF to start erase

delay (for loop)

wait for completion of the operation (CCIF -> 0)

Note the two delay loops. On my K60 the code runs fine without them, but they turned out to be needed for the target K20. Without them a reset occurs.
The delay loop works just like this:

volatile unsigned int i=0, tmp=0;

for (i=0 ;i<1000000 ; ++i) { tmp += 0; }

Also, note that the function at the end waits for the operation to complete.

2) Reading flash after write

This was not working well on both K20 and K60 until we applied some mechanism to refresh the cache.

On the K60 is seems that functions from the SDK handle that correctly.
On the target K20 that was not the case, in particular flash_cache_clear did not help. What did work for us was a number of "dummy reads":

static uint32_t read_val(void)

{

       uint32_t v = 0;

       // ugly hack to ensure correct reading of flash memory

       for (int i=0 ; i<10 ; ++i)

       {

             v = data.val;

       }

       return v;

}

Above, the structure "data" is located in the flash range of interest. It seems that reading twice is sufficient.

If you could shed any light on this case, please, help me understand what is happening.

Best regards,
Adam Rudziński

[mjbcswitzerland]

Hi

There flash interface for the K60DN512 and the K20DN512 are compatible.
Check that in both cases you are not erasing sectors in the flash block that is running code from (maybe this is the case in one of your codes).

Generally one disables interrupts and executes the Flash routines from SRAM - check that this is the case.

Regards

Mark

Complete Kinetis solutions for professional needs, training and support: http://www.utasker.com/kinetis.html
Kinetis K20/K60:
- http://www.utasker.com/kinetis/FRDM-K20D50M.html
- http://www.utasker.com/kinetis/TWR-K20D50M.html
- http://www.utasker.com/kinetis/TWR-K20D72M.html
- http://www.utasker.com/kinetis/TEENSY_3.1.html
- http://www.utasker.com/kinetis/tinyK20.html
- http://www.utasker.com/kinetis/TWR-K60N512.html
- http://www.utasker.com/kinetis/TWR-K60D100M.html
- http://www.utasker.com/kinetis/TWR-K60F120M.html
- http://www.utasker.com/kinetis/ELZET80_NET-KBED.html
- http://www.utasker.com/kinetis/ELZET80_NET-K60.html

uTasker: supporting >1'000 registered Kinetis users get products faster and cheaper to market
Request Free emergency remote desk-top consulting at http://www.utasker.com/services.html

Open Source version at https://github.com/uTasker/uTasker-Kinetis

[a_r_f_]

Hi Mark,

well, I expected compatibility, but something is different. Is the cache the same for both parts? Including any registers configuring cache?

The custom erase function was declared as executed from SRAM. I guess that FLASH_Erase from SDK was too.

I didn't disable interrupts, but in the tests no interrupt was asserted. I am perfectly sure about that.

The data were stored in a dedicated sector, program code was located elsewhere.

Best regards,
Adam

[mjbcswitzerland]

Hi Adam

Check the masks for the parts (I see that your K20 is a Z part and the K60 probably a second revision part, where there are some changes and errate fixes). In revision 1 parts you should not use speculation/caching due to erratas.
You may find that it is not a Flash problem if you do a detailed part comparison.

If you have a professional project requiring help you can request remote desktop consulting (first 40 minutes are free so even if you work for a zero-investment company it should be OK without the purchasing manager having a heart attack). See http://www.utasker.com/support.html and http://www.utasker.com/services.html

The uTasker project contains revision 1 and 2 compatibility options and is used in many K20 and K60 cross developments with mixed revision parts so a comparison between SDK and uTasker sources in the areas of difficulty will probably show which workarounds are needed.

Regards

Mark

[a_r_f_]

Hello Mark,

thank you for this explanation. I guess that in this case the problem with reading the new value stored in flash is justified.

But, is it possible that a function from SDK would work well only for the rev. 2 parts?

Best regards,
Adam

[mjbcswitzerland]

Adam

I don't use the SDK but I doubt that flash routines would be conditional on the part revision.

As noted, I am not sure that you have a flash issue but the test that you are doing may instead be failing for a different reason.

Regards

Mark

[a_r_f_]

Yes, I suspect that the problem with reading new data from flash is related to cache.

Concerning SDK, it would depend on what was buggy and if the SDK were fixed "backwards" for the previous silicon.

Best regards,
Adam

[mjbcswitzerland]

If you are suspecting cache coherency problems after flash erase you can command a flush of the cache by using

    FMC_PFB0CR |= (FMC_PFBCR_CINV_WAY_0 | FMC_PFBCR_CINV_WAY_1 | FMC_PFBCR_CINV_WAY_2 | FMC_PFBCR_CINV_WAY_3); // invalidate cache to ensure that it has no stale flash content after a flash modification

or

    FMC_PFB01CR |= (FMC_PFBCR_CINV_WAY_0 | FMC_PFBCR_CINV_WAY_1 | FMC_PFBCR_CINV_WAY_2 | FMC_PFBCR_CINV_WAY_3); // invalidate cache to ensure that it has no stale flash content after a flash modification

depending on the chip's register name.

Regards

Mark

[a_r_f_]

Hi Marc,

that was one of the first things I've tried, also with S_B_INV.
Best regards,
Adam