I am trying to work with the 'new' FLASH-controller-based Flash-block SWAP mechanism, as described in the new section 22.214.171.124 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