K60 flash write check

cancel
Showing results for 
Search instead for 
Did you mean: 

K60 flash write check

406 Views
aroste
Contributor IV

Hi all,

I have a K60FN1M with CW 10.5 and MQX 4.0.2 using PE for flash tools. 

I need to write 0x00000000 at an address (code entry point called from BOOT FNET) to "clear" the user firmware to enable next download. So I created a flash driver with PE and it works.

When the write is done I want to send back to computer the status of this action, so I read back the address and check that value is really 0x00000000. I have some issues in that step.

What I tried:

- loop of 10 times read with _time_delay(20)

- read until FTFE_FSTAT_RDCOLERR_MASK becomes FALSE.

- wait FTFE_FSTAT_CCIF_MASK becomes TRUE.

All this solutions doesn't guarantee that I successful read 0x00000000.  But the write is correct, in debug I can step few times and see in the memory window that suddenly the values change.

Could someone help me with that ?

Thanks

BR

Stéphan

Tags (2)
0 Kudos
5 Replies

115 Views
aroste
Contributor IV

hi all,

I'm back to try to fix that.

So I understand your different points.  In the first code version I use the Flash_LDD to write the 0x00000000 at my address then a pointer to read back.  I checked the disassembled code and the address is correctly read each time in the loop.

I try to change with the FlashRead_LDD function from PE. 

Steps are:

Init_LDD     (falsh component)

Write_LDD (write 0 at address)

Main_LDD (do the write)

Main_LDD (reset status to "idle")

Read_LDD (read at address)

Main_LDD (do the read)

In debug it returns the correct value but in release not.  It takes some time to update the value it seems. 

0 Kudos

115 Views
OliverSedlacek
Contributor III

I've found that there are two places where the old memory values may be lurking. The first one is in the FTFE block and the second one is in the LMEM local memory controller (memory cache to most people). Turning the LMEM cache of is quite complicated, so I think I resorted to running a verify loop over a large address range to force the LMEM to fetch a fresh copy. What's confusing is that the debugger seems to bypass the LMEM, so what you see is different from what the processor sees.

0 Kudos

115 Views
aroste
Contributor IV

I tried in debug stepping and also I let the software running.

I return to computer a status message to confirm either or not the value is cleared.  I do a loop and perform several read, but always at the same address. Maybe that is the issue.  I should try another address then again the good one.

0 Kudos

115 Views
Hui_Ma
NXP TechSupport
NXP TechSupport

The flash memory controller will come up in a valid configuration with the cache and pre-fetch buffers enabled.

If a firmware driver is used to program flash values, then a flush of the cache might be needed. The cache has no means of snooping to know when a program operation occurs, so a flush is needed to ensure that the cache does not return stale data.

firmware driver is used to program flash values, then a flush of the cache might be needed. The cache has no means of snooping to know when a program operation occurs, so a flush is needed to ensure that the cache does not return stale data.

Wish it helps.
Best regards,
Ma Hui

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

0 Kudos

115 Views
ndavies
Contributor V

What programming language are you using? Are you using C with optimization turned on? If so you must mark the variable that points to the address you are reading as volatile. Creating a loop that reads a variable multiple times will only read data once out of flash into a register. The register will be compared multiple times but never updated. Marking it is as volatile will force the program to reload the variable each time it is tested.

0 Kudos