pFlash Swap SW reset, HW reset etc

[mrandreas]

Hi,

For the 1MB pflash chip is it possible to PFlashSwap between Four or Two blocks?

(MK10FN1M0VLQ12 or MK10FN1M0VMD12)

On power loss or HW reset is it possible to "boot default block" while sw reset performs boot of current running or swaped block?

Example:

Start  BLOCK0 -> Do Swap to BLOCK1 ->  SW reset -> Starts Block 1 -> HW reset/Power Loss -> Start BLOCK 0?

thanks

Andreas

[mrandreas]

Any clues on this question? I'm in a position where I have to choose between 50 % Flex or 100 % pflash with swap. If the flashSwap doesn't support a "default boot block" to start after Power loss or HW reset I most likly choose 50 % flex.

Since I so far has not found the "Default block on Power loss or hw reset" functionality I'm guessing that it doesn't exist. Am I right... am I??

thanks

Andreas

[egoodii]

I don't think you can make a 'hardware' force-function as to which flash-half to boot from based on the 'reset reason'. Once you have validated a flash-half-burn and set the 'next boot' to that image, that is what you will run. You should be able to make a decision 'early on' in both images as to the cause and make a decision whether to 'stay' or 'revert'.

Personally, I abandoned the 'swap' mechanism when Freescale made it so specific in its operational modes -- we had more control over the first form.  As a result, we now put a cheap 75-cent SPI EEPROM (1MB) in our systems, and dedicate the first 16K of Flash to a bootloader function.  The bootloader CRCs itself, and the application image, and also looks into the EEPROM for a 'code update' image.  If it finds one, it burns said image before jumping to the application.  We can use the full 'Ethernet' connectivity of the application, for instance, to load the EEPROM with the 'next version' code.  Within the application image operations is a process to 'validate' the general operation, and if it finds itself capable of all proper operations, it 'validates' the code image stored in the EEPROM.  If a reset comes about before such validation, then the bootloader will 'scratch' that image, and re-burn the next-older image in the EEPROM to revert to something that worked.  The bootloader can also overwrite itself from one of these images, but of course without that original 'I was in control' swap mechanism, I can no longer make that 'bulletproof', so there is a weakness there if something happens during bootloader self-update (so don't do it very often!).  So with all this we get some complete control over what gets programmed, AND we get to use nearly ALL the flash within the Kinetis part for functional code.

[mrandreas]

Thanks for the perspectives!

Since you have chosen a chip with EEPROM I guess you use FX series?

If space is not an issue and the power safty swap feature is not an issue you would go for a small boot loader in EEPROM that supports SW download, checking of the downloaded software and jump to sw.

Her is the chip data:

Freescale part number	Total flash	Program flash	FlexNVM	FlexRAM	SRAM
MK10FX512VLQ12	1 mb	512kb (NO SWAP)	512 kb	16kb	128
MK10FN1M0VLQ12	1 mb	1MB (SWAP)	-	-	128

The datasheet and ref man does not say anything about the lifetime of the FlexNVM. How many times is it possible to write to the FlexNVM?

[melissa_hunter]

Hi Andreas,

There is a calculator tool that can be used to determine the number of writes for different FlexMem configurations:

http://cache.freescale.com/files/32bit/software_tools/emulation/TFS_FLEXMEM_CALCULATOR.zip

Hope this helps.

Regards,

Melissa

[egoodii]

I wasn't clear about our setup.  The 16K 'bootloader space' is in the Kinetis on-chip flash, in low memory using the default vector table.  We have our IAR toolchain set up to accept this bootloader image as an 'import' to the complete chip image, and we also have those tools inserting the CRCs for us (and filling empty space with a breakpoint instruction).  We have MQX in the application putting the ROM vector table in 'high memory' for the default application vectors.  The EEPROM I speak of is an external M24P80 chip, and is ONLY used for 'update image' storage (two copies - current and 'update').  By the way, one of the bootloader functions is to allow an S19-file upload to that external SPI EEPROM to manually get an update image into there as a 'fallback' option.  Updating the application-space within the bootloader (from this external EEPROM) is 'fully safe', as any interruption will leave the application space failing any CRC test, and so the bootloader would retry the image burn.  I have been using MK60DN512ZVMD100 and MK20DN512VLL10 in this mode.

I have never used Kinetis FlexNVM, but I believe FlexNVM write-endurance is inherently the same as program-flash, in the 10K range.  However, when used in 'EEPROM' mode there is an over-allocation strategy that multiplies that endurance, up to the point that if you are willing to commit to a 32,768 flash-to-EEPROM ratio you can expect >>80M.  I am not directly familiar with the chips you list, but in the datasheet K60P144M100SF2V2.pdf this is spelled out in section 6.4.1.4.