Using K64 flash swap mechanism having problems

[embedbytes]

I have implement the standard flash swap mechanism within my K64 based application. The process seems to be working fine, I can downloard multiple apps and the mechanism ping-pongs as expected, no problem (everything is fine over power cycles as well). The issue I have is executing a download from JTAG after the swap mechanism has been used. If I try a 'download & debug' via the IDE after a swap event has occurred I get the message "The flash loader program reported an error" and the connection terminates. The only recover from this is to execute a mass storage erase. After that I can debug via JTAG. Im looking for some guidance on what could be causing this.  

[Jacob_Simonsen]

Hi guys,

sorry to break in on the discussion, but you seem to know this detail:

For the K64F with 1Mbyte Program Flash only, the Flash command "Read Resource" did not return values in the order I expected.

Technical manual 29.4.12.14.1 says "Program Flash Swap IFR" at resource local address 0x040000 contains "Swap Indicator Address", "Swap Enable Word", "reserved bytes..".

I expected that returned as a byte block copy into FCCOB registers -4 through -B, but that gives 00 00 7F FF 7F FF 7F FF.

(When my initial "Swap Indicator Address" was supplied as 0x07 FF F0, I expect to find that truncated as 7FFF)

The FCCOBn (n=0-B) registers are mapped to address 0x4002 0004-F, but the register names are not ordered by increasing address.

The returned bytes makes more sense when assuming the 8 bytes are block-copied from the "Swap IFR" to the start address of registers FCCOB4-B.

The manual 29.4.12.4 Read Resource Command says "Read Data[] goes to FCCOB, in the order of the register numbers B, A, 9, ...4.

How are the content bytes of "Program Flash IFR" ordered in the "returned values" of "Read Resource Command"? 

Kind regards

Jacob

[myke_predko]

Hi @embedbytes 

I've seen the same behaviour when I've used the swap function.  

As I understand it, this is a security feature built into the design which does not allow programmer writing to the Flash unless the 1K IFR EEPROM (which has the boot block information) is in the default state.   

If the IFR EEPROM could be accessed/written to, then the Flash Blocks could be swapped by a malicious user and a program written into the new "Block 0" to read back the contents of the formerly "Block 0" Flash.  

So, if you are going to use the swap function, you will have to load the updated firmware into "Block 1" using the code in "Block 0" rather than an external programmer.  As part of the "Block 0" code, I recommend that you erase "Block 1" before loading in new firmware to ensure that all of your code is safe.  

myke

[embedbytes]

Thank you for the feedback. Do you know if NXP has confirmed that this behavior works as designed? if so I can move on.

[myke_predko]

@danielchen , @jingpan or anybody else at NXP - can you confirm what I've written.  

I was told about the IRF swap protections in 2012 by a Freescale FAE who is not with NXP.  I have found the email and what I wrote here seems to be essentially correct.  

myke

[jingpan]

Hi,

I can't find related notes in RM. Since K65 sdk has flash swap demo, I tested on TWR-K65. The debug still can work after swap. So, I think this is not the problem. Please check 0x400 area after swap, maybe the JTAG or memory is protected.

Regards,

Jing 

[myke_predko]

@jingpan 

Are you attempting to write to Flash from the debugger?  

The problem isn't debugging after a swap, but having to do a mass erase when trying to load a different Flash image into the device.  

myke

[jingpan]

Hi,

Yes, after swap I can download a 'Hello world' and debug. The FCNFG.SWAP bit is 1 at this time.

Regards,

Jing

[myke_predko]

Hi @jingpan 

Interesting - what's the process/tools you use to be able to do that?  

When I've tried it with JTAG (P&E and Segger) debuggers, CW & MCUXpresso, I have to accept a delete before loading anything like @embedbytes 

Thanx.

[jingpan]

Hi,

I use a TWR-K65 with CMSIS-DAP and MCUXpresso 11.3. But that should not be this kind of problem. I think there should be some configuration problem.

Regards,

Jing

[myke_predko]

@jingpan 

Along with the development tools, which programmer firmware are you using?  

myke

[jingpan]

Hi,

You mean the openSDA? It's DAPLink.

[myke_predko]

@jingpan 

That's what I'm asking - I'm about to implement it on a product and I'll try first using OpenSDA followed by the other programmers and report my experiences.  

This will probably over the next two weeks or more.

myke

[embedbytes]

Plerase keep me posted if anyone figures out what the config issue might be

[embedbytes]

I am experiencing a new problem with my FLASH swap implementation and would like some feedback if anyone has suggestions. As stated earlier I have successfully implemented the flash swap mechanism in my K64 application and for the most part it works fine. As a test I have set up the code so after the flash update is complete the system resets itself and repeats the process. With that said, I can see this test execute 500 or more times without a problem, however, randomly I get a CPU LOCKUP during one of the cycles. (could be cycle 3 or cycle 300). The cpu lockup causes a reset and I can see the source of reset in the RCM register. I am having alot of trouble determining what the source of the cpu fault is because i cant use the debugger due to the fact the system performs a reset thus disconnecting the debugger and I never know when the fault will occur. Its confusing to me how the firmware can apparently execute fine 200 times then cause a cpu lockup. Any feedback I can get would be great. 

[jingpan]

Hi,

I checked through Kinetis family and find that K22FX512 has this problem. But K64 hasn't such problem.

https://www.nxp.com/docs/en/errata/KINETIS_K_3N03G.pdf

Please check 0x40C value. You can let your program print the value via UART.

Regards,

Jing

[embedbytes]

Reading the register at power up and its always 0xfe

[embedbytes]

The CPU LockUp always seems to be occurring during the FlashStart, FlashFinish and FlashSwap but never during the FlashProg. I'm at a loss to the problem, I've disabled iinterrupts before Flash command processing so Im not sure were the confict is coming from.

[jingpan]

Hi,

Sorry for reply you late. I made a demo just by copying K66 swap code to k64 pflash project. It works well. After run this demo, you can still debug or debug other k64 project. The SWAP bit in FTFE_CCNFG register become 1.

Regards,

Jing

[embedbytes]

Thank you for the reply. I will review your example and make sure I am executing the process similarly. I di d identify my core-lock-up issue. Although I thought I was disabling all interrupts during the flash update it turns out I wasnt. Once I got all the interrupts silenced the process seems to work fine. As I said, I will review your example to identify my debug issue after flash. Thanks again.