New Kinetis Flash SWAP mechanism

[egoodii]

I am trying to work with the 'new' FLASH-controller-based Flash-block SWAP mechanism, as described in the new section 28.4.12.14 in Rev 5 of the Family Reference Manual (I am working with the 144-pin K60, as it happens).

Firstly, while this section may be a decent description of the chip functions, it is rather poor at describing how one would best USE this functionality to implement a reliable system update process.  For instance, table 28-67 details a number of combinations of 'fault' the system as a whole must contend with, but I THINK it is sufficient to test MGSTAT0 for '0' and a State Code of '1' to indicate a 'non fault' condition coming out of reset -- anything else means something happened along the way.

One thing that is NOT defined in ANY reasonable way I can discern is the use of the 'Flash Address' in each command.  It sort of reads like this is some kind of 'password' that is set by the initialize command and must match in all other commands, BUT I set this to a non-random 0xA530 pattern, and NOW my IAR debug-download (thru Segger Jlink 4.34a tools) complains that it can't erase the sector starting at 0xA000, and I can no longer download code! (Although it appears to me that all 496K from 0x4000 to 0x7FFFF is erased.) So, one question is, is there any way to return this SWAP state machine to the uninitialized state so I can get my chip working again???

In any case, my issues might stem from a deeper issue relative to how this swap mechanism is designed to work, as opposed to how I WANT to use it.  The previous swap mechanism (a battery-backed bit in the RTC section) did nothing more or less than fully swap the 256K flash blocks.  SO, how I HAD been using 'swap' functions was as a 'safety catch' mechanism to reliably update the bootloader.  That is, I have the first 16K block (minimum FPROT register protection size), as contains the reset vector, dedicated to bootloader space.  The remaining 496K is all application space which the bootloader can update, in our case from external SPI memory downloaded previously (two total images there for necessary protection from a fatally flawed update).  So, the SWAP function would come in when I need to update the actual bootloader itself as part of some major system change.  For that, what I HAD been doing is to:

1 - copy the current bootloader out to 0x40000 (start of second 256K).

2 - if that works, set the 'swap' bit so that from this point ANY reset will restart the original bootloader

3 - erase the first 16K and load in the new bootloader image.

4 - if that all goes well (CRC passes) then clear the 'swap' bit and hit reset to run the new code.

5 - for ANY failure, including a reset while the banks are swapped, indicates a need to restore the original bootloader

This way the system is almost ALWAYS running the banks in 'normal' 0/1 order.

Firstly, I don't see that I can use the new 'swap' function for just this 'backup' function as I was doing -- the diagram clearly indicates a need for 'resets' and erase operations in each bank to move around the states.  But I do have a fundamental concern here as well -- while this mechanism is discussed as a SWAP process, the descriptions talk mostly of which bank is 'active' (at address 0) as if the 'other bank' were somehow not 'fully normally accessible' at the 256K address.  Can I still get my full 496K application space with this new SWAP initialized?  Or is this whole operation geared directly at applications that have two 256K 'application spaces' that one would ping-pong between?

Earl Goodrich II

[egoodii]

I have no particular proof, but I have a feeling the swap-flags need to reserve a whole phrase.

[rtlaka]

Seems you're right, I modifed my original code to reserve a phrase, that did the trick.

Org. not working. Phrase Aligned address 0x500 but not whole phrase reserved , eg. not kept erased.

        FILL(0xFF)
        . = 0x500;
        swap_indicator = .;   
        KEEP (*(.swap))
        . += 4;

Increase the size, worked.

        FILL(0xFF)
        . = 0x500;
        swap_indicator = .;   
        KEEP (*(.swap))
        . += 8;

[rtlaka]

What do you consider as the proper reset procedure to get the new swap running?

I implemented the warmreset I found on this forum, eg. writing

   read_value &= ~AIRCR_VECTKEY_MASK;
   read_value |= (AIRCR_VECTKEY(AIRCR_VECTKEY_WRITEKEY) | AIRCR_SYSRESETREQ);

//rtlaka

[egoodii]

That looks to be the gist of the ARM core reset hook.  Our code is:

void_t Os_CpuReset ( void_t )

{

/* request Cortex core reset, which will cause the software reset bit to

* be set in the mode controller for recognition after restart

*/

    SCB_AIRCR = (SCB_AIRCR_VECTKEY(0x05fa) | SCB_AIRCR_SYSRESETREQ_MASK);

    while (1) {}

}

[egoodii]

Thank you for this specific clarification on Rev's.  I don't think the 1.4 enhancements will help my attempts to use this mechanism to support a bootloader, and the 'reliable' update desires thereof.  The flag words within each image still create difficulties.

I would also like to remind anybody looking at these silicon changes that the change to the swap mechanism from the 'old' RTC_CCR register at offset 0x1C in RTC space in 1.0 silicon came with a change to that register definition!  It is now a RealTimeClock_InterruptEnableRegister at the same 0x1C offset, so operations at the 'old' CCR assumptions will mess with RTC interrupts you may be trying to use.

Earl Goodrich II

[Dekiru]

There is no way to recover the original state if you enabled swap feature once.

It means that "Erase all" command will be disabled and you cannot use Jtag debugger to flash it anymore...

We haven't tried EzPort yet. It might be an alternative way to get the chip flashed when swap feature have been executed.

To touch with swap feature, you should start with a downloader to write data from external media to 2nd flash block , confirm that it works fine before enable swap.

You should have 3-5 boards/chips on you hand before playing with this

Regards

[eengineer]

You have GOT to be kidding me!

I just spent a week deciphering the truly pathetic app note AN4533 "Robust Over-the-Air Firmware Updates Using Program Flash Memory Swap on Kinetis Microcontrollers". It is pretty much useless because it still uses CodeWarrior and KDS1.2 and has not been updated to reflect KDS3 and SDK2.0 which are now recommended. I managed to get Flash Swap working, amazingly, despite the multiple bugs I found in the 2.0 API... nice job testing and properly documenting that code, folks!

I kept figuring I was overlooking something with the fact that the "Disable Swap System" command requires the current swap state to be Un-initialized, and I couldn't find how to get back to Un-itialized! After all, what in the H--L would be the point of having a flash swap for over the air reprogramming if it could only be used once, and then could never be recovered without manual intervention? Only morons would implement such a feature.

Of course I failed to realize just how inept NXP engineers could be, and that's exactly what they've done. Maybe they could explain how the word "robust" in the AN4533 title is justified for something that is irreversible without manual intervention?

I didn't think NXP could possibly be more negligent than M---p with the P--32 garbage, but I am reconsidering my opinion.

If NXP believes their position on this "feature" is defensible, then there is NO excuse why it doesn't say in HUGE letters on the front cover of AN4533... this feature can only be used for ONE UPDATE and never used again without completely bricking your device.

I just shake my head in amazement that a company would even have the audacity to claim "flash swap" is a useful feature.

[egoodii]

I don't quite understand what Dekiru is looking to do --- the 'disable swap system' command only exists for the 'rare, surely engineering-only-case' where you want to return the part to 'non-swapping' operation.  In any 'deployed product', once you have 'enabled' the swap system, you WILL be forever running in that mode, where the 'swap hardware' makes a decision at EVERY reset as to 'which bank' to enable at address zero, subject to the update-sequence required to install a firmware update.  The update process must always be working on the 'non active' bank, and be aware of the running swap-system requirements.

[mjbcswitzerland]

Hi

Please could you take a look at this: https://community.nxp.com/thread/379755#comment-587268  ?

At the moment I am not sure whether there are potential problems with the mechanism, although II have used it for more than a year and never experiencing any problems with not being able to program flash any more. I never lost a chip during development and so either I missed something or have been doing other things to those discussed here (?). It allows two loaded SW versions to be swapped between without any problems.

The method is integrated in the OpenSource uTasker Kinetis project available at
http://www.utasker.com/forum/index.php?topic=1721.msg7086#msg7086
which would save what seems like hundreds of companies re-inventing it each time (and typically losing about a week of work in each repetition).
Note also that the swap mechanism is emulated in the project (when built with VisualStudio) which may help understanding (and certainly development and testing).

Regards

Mark

Professional support for Kinetis: http://www.utasker.com/index.html
Remote desktop one-on-one coaching: http://www.utasker.com/services.html
Getting started to expert videos: https://www.youtube.com/results?search_query=utasker+shorts