mk64 read from flash 0xE5FF8 causes busfault

[theadib]

Hi,
i have a board running MK64FN01M similar to what FRDM_k64 has.

I do store settings on the flash on the last bytes I store a CRC.
For one sector on the board I get Bus faults when reading that section

the code calls a simple memcpy from 0xE5FF8 to RAM with length of 8 bytes.
This function in this code is called before with different memory sections.
only on those location the code crashes.
When I move this sector to other location, then it works.

Any ideas why that specific memory migth be problematic?

Thanks, Adib

[Alice_Yang]

Hello @theadib 

Please first erase the entire sector, then write your settings data (including the CRC) aligned to 8-byte boundaries. Do not perform partial updates on the same 8-byte phrase. After that, proceed with the read operation.

BR

Alice

[theadib]

Hello Alice, thanks for your reply.
The Bus fault happens during read operation (memcpy from flash location)
What could cause Bus fault using regular flash address?
There was no write operation before.
Is it possible to persistently "block/protect" flash from reading.
My program was working on other devices ok.
Any ideas?
Thanks, Adib

[Alice_Yang]

Hello @theadib 

There is the FSEC register. The SEC bits in FSEC determine whether the MCU is in a secure or unsecure state. While this controls the entire MCU, in your case only some memory cannot be read, so I don’t think this is the reason.

It’s possible that an error occurred during the previous write operation, so I recommend erasing the memory first, then reading it again to check whether it works properly.

Thank you.

BR

Alice

[theadib]

Hi @Alice_Yang 

sorry for bothering you ...
I now traced down the root cause to a double write to the same address with the same data.
This should not happen in a bug-free code
However,
the second write returns an error code
but then even a read to that sector causes that BUS_FAULT trap.

Is there a possibility to check the sector status before an access causes the whole program to crash?
So that I then can properly erase the sector again and put the sector in a correct state.
???
I have checked the FSFE description in the Reference manual section 29.4.10.2 Flash commands.
But I see not a command that can "test" a sector from a program memory. 
Am I missing something here?

That way I could make more resilient application to check the Flash status after reboot.


Thanks in advance,

Adib

[Alice_Yang]

Hello @theadib 

After launch the Erase Flash Sector command, the FRFE erases the selected flash, then verifies that it is erase.   If the erase-verify fails the FSTAT[MGSTAT0] bit is set. The CCIF flag is set after the Erase Flash Sector operation
completes. The Erase Flash Sector command is suspendable (see the FCNFG[ERSSUSP] bit and Figure 29-11). 

BR

Alice

[theadib]

Hi @Alice_Yang ,

maybe this problem with some weird behaviour I recognize using my SEGGER JLink.

When I connect to my MK64FN1MOVLQ12 using MK64FN1M0XXX12 in JLink, then:

device MK64FN1MoXXX12

if SWD

speed 1000

connect

erase
loadbin imagefile.bin 0

usually the JLink claims the device is protected after erase.
and presents this attached dialogue.

I would have expected the device is unprotected and unsecured after erase command.

What should be the preferred sequence using JLink to completely erase the flash and load new image?


 Thanks in advance

[Alice_Yang]

Hello @theadib 

When using J-Link to erase, there are two options for the same chip. Please choose the device name without “allow security”; this way, it won’t be secured after the erase.

Thank you. 

BR

Alice