Development of Swap in FRDM_K64

[pidgeydoyle]

Hi everyone,

I'm new to Freescale and I am beginning development using the Freedom K64 board.

One of the main reasons for changing to this uC is to utilise the firmware swap function.

I was looking for advice on how best to go about bringing the flash_demo example code into real world use.

In the long run I need the following:

1. new .bin firmware file is downloaded to GSM module.

2. .bin sent to uC over UART.

3. new firmware image is programmed to upper block.

4. uC firmware swap changes to new firmware.

What do you guys think would be a good way to begin the development of this?

I would really like to get a proof of concept working for the firmware swap.

Do you guys think it would be a good idea to try to include a separate compiled firmware version in the code that is programmed onto the uC and try to use that as the Firmware to be swapped to?

Any advice would be great.

P

[mjbcswitzerland]

Hi

>>A bootloader combined with two copies of APP code is the best practice, but I am not sure this can be realized in Kinetis SWAP case.

This is possibly by loading not just a new application but a combined serial loader/application image and then swapping that.

Regards

Mark

[zhiqunhu]

Following the discussion in the link is helpful since I need to determine how to do In System Programming for a new design with a K64 device.

I think the biggest advantage of two copies of code SWAP over a serial bootloader is the device which needs to be updated can still operate at the normal mode, does not have to be in bootloader mode.  That is essential for many applications.

The biggest advantage of a bootloader is it can recover the system for update in any condition.  So there is no condition that system/device will be in "dead" state.

A bootloader combined with two copies of APP code is the best practice, but I am not sure this can be realized in Kinetis SWAP case.

[pidgeydoyle]

I understand that the flash_demo example copies the existing firmware from the lower to the upper block but what would be the best way to temporarily store a new firmware image after receiving it over UART.

Do I need to temporarily store the new image and then perform the swap or can I perform the swap on a byte by byte basis as I receive it from UART?

Thanks.

P

[Hui_Ma]

Hi Peter,

You are right. There doesn't need a bootloader routine if using Flash SWAP function.

The application in Flash lower block has capability to load and program the new firmware to Flash upper block via UART.

1> First of all, the Flash upper block need be in erased state;

2> According to some signal, the application load the new firmware image from UART and program it to Flash upper block;

3> When the new firmware was programmed successfully, the application could execute SWAP command to swap the application.

As Mark said, the new firmware also has the same capability to do firmware load and program function.

The [flash_demo] example simulate copy image from Flash lower block to upper block, then execute SWAP command. The actual application need load the new firmware from UART and program the Flash upper block using Flash program phrase command.

Wish it helps.

Have a great day,
Ma Hui

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[mjbcswitzerland]

Hi

I have attached a "real-world" application that uses the swap feature, runs on the FRDM-K64F and loads new code over the UART.

In the attached file "uTaskerSerialBoot_SREC_Swap.zip" there are two versions of the application (each as a .bin and a s19 file). One has the version number V2 and the other the version number V3 so that it is easily seen that the swap has been done between 2 different software versions.

To use:

1. Load either xxxxV2 or xxxxV3.bin to start with an initial application. Assuming that the swap mechanism hasn't been used before (or after a full chip erase) it will be seen that it is uninitialised. The virtual COM port uses 57'600Baud and the following screen is displayed at reset.

Swap uninitialised

uTasker Serial Loader V1.2

============================

[Swap size 0x00080000]

bc = blank check

dc = delete code

ld = start load

sw = swap memory

If the blank check is performed (this is checking the alternative flash block) it will initially result in it being empty. If it is not, command a delete to erase it.

2. Now load the alternative software version as SREC file using the load command. I recommed TeraTerm as terminal emulator since one can drag and drop the file onto it to do a transfer.

First command "ld" and then copy the file. It will look like this (each dot is a programmed s-rec line), whereby the SREC is being copied to the alterative flash block:

> ld

Please start S-REC download: ...............................................................................................................................

...................................................................................................................................................................................

...................................................................................................................................................................................

.................................

Terminated - swap if required

After the complete code has been programmed the Flash block is not swapped automatically - with the "bc" command it can be seeen that the flash is no longer empty.

In this state the original software runs after a reset, although the new/alternative SW is in the alternative block waiting to be activated.

3. Command the swap using "sw" and then confirming it.

> sw

Swap memory [y/n] ? >

Swap OK - resetting...

Swap using 1

uTasker Serial Loader V1.3

============================

[Swap size 0x00080000]

bc = blank check

dc = delete code

ld = start load

sw = swap memory

After the swap has completed (takes a few hundred ms) "Swap OK" is indicated to confirm that all went well and then a reset is executed after a short delay.

It is seen that the new block is now used (a reset is always required to finalise the swap).

The flash swap block being used is shown as block 1.

4. Either new S-recs can be programmed using the same technique (for a guide to the operation see http://www.utasker.com/docs/uTasker/uTaskerSerialLoader.PDF ) or else it is possible to switch between the two programed software versions using the "sw" command again. For example, when I do it in this state:

> sw

Swap memory [y/n] ? >

Swap OK - resetting...

Swap using 0

uTasker Serial Loader V1.2

============================

[Swap size 0x00080000]

bc = blank check

dc = delete code

ld = start load

sw = swap memory

Now the block 0 is being used again, where the original software version is.

This can be repeated to quickly switch back and forward between the two available software versions.

One extra bit of information is that the mechanism also requires a sector in both blocks for use for a state value - the final sector in each block is thus reserved for this so the application size is max. 508k (half the flash = 512k - one sector of 4k).

This is thus a "real" application that allows the UART to be used to load the new code and also controls the swap mechanism. I used the uTasker SREC loader as base but the same is possible by including the swap part in the uTasker application and then doing the update via USB-CDC or Ethernet.

The question is however whether that is already the end of the story, and in my opinion is is certainly not!

Although the swap machanism (in its version V1.4 I believe, so I don't know whether it is recommended on older chips) tolerates power loss or some other failure during the swap process (in that case it should continue to completion after the next power up) this in itself is not a guarantee of a robust solution - it guarantees only a small part of it and in fact also not necessarily the most important part of it either.

Consider the following possibilies:

1. I command a swap 'before' I have loaded the new code. Now the board doesn't work and has to be sent back to the manufacturer for programming!
- solution is to not allow the swap until it is know that there is new code present.

2. I load a new software version that has an error in 'its' loading mechanism. Now I swap and the new version operates and I delete the original version becasue I want to upload a new one again. Now I can't continue - the board has to be sent back to the manufacturer for recovery.

- solution is to ensure that only fully verified code is loaded (best with some authentication to ensure that no one loads unverified code)

3. I load code but something goes wrong - eg. power loss during loading - but I don't check carefully and still command a swap.Now I have lost control and cannot even restore the previous version (which is stil in memory) since the new code is needed to command a swap back again. Again 'bricked'.

- solution is to ensure that the integrity of the alternative application can be verified

It becomes quite clear that a small boot loader sometimes is quite useful to ensure that recovery is always possible. The advantage of the swap block method is not really in the uploading - it is no more simple or robust than a small boot loader, but it does have that nice feature that when there are two good software versions loaded (that don't cause control to be lost) one can very easily and quickly switch between the two. Also the two software versions are pure-standalone versions that don't need special linking to operate together with a boot loader.

To ensure the advantage a little more is needed in the software that is prepared for loading and in its operation:

1. It needs to be authenticated - the swap must not operate if the software can't authenticate the new software because the risk is simply too high. The binary loaded must include some form of authentication (key) that can be checked.

2. The swap should also not be possible if the code in the alternative memory is not know to be correct. If this can't be done with the authentication key the binary should also include details about its size and a CRC so that the initial application can verify that its integrity in flash is OK.

Therefore I will look at adding authentication and integrity checking (maybe MD5?) in the applications and then I think that the technique should find some good uses.

Regards

Mark

[pidgeydoyle]

Thanks Mark,

This is really helpful, thank you very much.

It works really well. I guess I just need to try implement something similar myself!

Can I ask what is the benefit of providing the Firmware to be swapped in SREC format as opposed to .bin?

I haven't had a chance to really get into this yet.

You make some really great points, it can be a pretty risky operation if not implemented correctly. In my application use of this system will be fairly infrequent so I think a big part of using this will be to extensively test the update process every time there is a new update not only to check that the new version boots correctly but also to ensure that the new version can itself accept upgrades.

Peter

[mjbcswitzerland]

Hello Peter

Loading as SREC over UARTs can be useful due to the fact that the content is ASCII HEX and so also XON/XOFF flow-ontrol can be used. When sending binary files the XON/XOFF flow control couldn't be used since it would be triggered randomly by data content.

XON/XOFF also alows progamming blocks of data that are at specific addresses, whereas binary needs to program a known complete block since it has no addressing contained in its content (althugh Motorola binary is an exception). Generally binary need an additional coding of some form (header, paket protocol) to make its use flexible and reliable.

Regards

Mark

[mjbcswitzerland]

Hi

I had a few minutes to kill so decided to do somethig a bit more interesting (although I have to admit that it turned into a couple of hours - or more - of actual work).

Attached is a new 'real-world' swap block update application which allows loading the new software via UART as SREC, as in the previous version. In addition it however also allows updating via USB-MSD (i.e. both methods can be used) and, since the SREC is compatible I'll just explain the more interesting USB method:

1. When connected to a USB host the board appears as two external hard-drives - one called "UPLOAD_DISK" and the other called "ACTIVE_SW". The ACTIVE_SW disk is write protected so can only be read. On the disk the present software is seen (as a file with its name, time/date and size) - it can't be deleted since it is what is running but it can be opened (to view the Flash content) or copied back to the PC.

UPLOAD_DISK is read/write and displays the firmware that is presently in the swap block if it is present (or is empty if there is nothing in it). Again it can be copied back to the host if desired.

It looks something like this (with one of the drive's content showing):

2. In order to load a new firmware to the FRDM-K64F any existing software in the swap block (on the "UPLOAD_DISK") can be deleted (either with the delete command via the UART menu or by simply deleting the file on the hard-drive and a new version the copied (by drag-and-drop to the disk). The USB-MSD operation is described in http://www.utasker.com/docs/uTasker/uTaskerSerialLoader.PDF if needed.

3. When the new firmware has been copied the disk displays its name, time/date, size of the image but hasn't swapped it just yet.

4. To perform the swap either the "sw" command can be used on the UART or else the "UPLOAD_DISK" can be ejected (using the eject command in the file manger). The eject is used to invoke the swap and the new firmare starts operating after a short delay (approx. 1s).

5. After the swap, the device enumerates as the two external hard-drives again and it can be seen that the software versions have effectively been swapped between the two disks. Using the "sw" command or the eject method the two software versions can be switched between as before.

During the work I found one thing to be aware of with the swap mechanism: if the address used for the Flash Swap Indicator is changed it is necessary to do a full chip erase before it operates. The reason is that the address has been programmed into the swap memory and commands will fail if the used one doesn't match with the programmed one (that was programmed as some time in the past). Therefore it is best to choose an address and stick with it - in case of failures (no commands working) the chip erase is needed to delete the swap memory too and then all starts working normally again.

If you have two FRDM-K64Fs the firmware from one (either the active or the swap block one) can be copied from the drive to a different board in order to transfer one of the firmware versions (or both) to it.

Although probably of no practial use, but, one can also drag and drop the working firmware (on the "ACTIVE_SW" drive) to the "UPLOAD_DISK" drive to have the same on both.

How it was programmed:

a. I started with the uTasker USB-MSD loader which allows updating firmware to a single drive (so didn't have to develop the compete read/write operation)

b. Then I enabled a second drive (this is controlled by the FAT emulation module - http://www.utasker.com/docs/uTasker/uTaskerEmulatedFAT.pdf) and effectively assigned the first half of Flash to the write-protected drive that I named "ACTIVE_SW" with read-only capability (it is also possible to protect this with a password so that the code in the device can't be read out by anybody). The second half of Flash (with read/write/delete access) is assigned to the drive "UPLOAD_DISK".

c. Finally some tuning and testing to ensure that all addresses were correct and that all stages of programming (with/without sofware, swapping) displayed the disk contents understandably. When firmware is loaded via the UART it appears on the drive as a file with fixed name since it has no file object like the USB-MSD copy has.

I committed the work to the uTasker serial loader project so that it is possible to choose this SWAP block mode (on USB-MSD and/or UART) or use the original stand-alone loader mode. Switching between the two is controlled by a single define (MEMORY_SWAP) and will work on all devices with the swap machanism as long as the swap block size is confgured suitably.

Regards

Mark

Attached:

- uTaskerV1.4.bin
- uTaskerV1.5.bin

Two binary versions for loading via USB-MSD
- uTaskerV1.4.srec

- uTaskerV1.5.srec
The same in SREC format for loading via UART.

[mjbcswitzerland]

Peter

I don't know that there is any real practical advantage of using the Flash block swapping.

Your present application needs to save a (complete) new software image in the alternatlve Flash block (limiting the maxium SW size and any further Flash usage to half of the available memory). Then it needs to command the block swap and restart the processor so that the new code operates.

The code used to do this needs to be in the application and needs to carefully check the integrity of the new code otherwise it risks leaving the device in an unusable state (needs to be returned to the factory for re-programming). This is possible without a boot loader (doing the swap in SRAM).

The same can be done using various fail-safe methods without needing swap block support, including performing the swap in SPI Flash so that no code space is lost, storing encrytped code to exclude reverse-engineering possibilities (code-protection) etc. - or of course using a dedicated boot loader allows almost all code space to be used and no work for the applicatiion.

Regards

Mark

Kinetis: http://www.utasker.com/kinetis.html

Bare-Minimum Loader: http://www.utasker.com/docs/uTasker/uTasker_BM_Loader.pdf

Serial Bootloader (Ethernet, USB, MSD, KBOOT, AN2295, SREC, SD-card): http://www.utasker.com/forum/index.php?topic=1873.msg6796#msg6796 / http://www.utasker.com/docs/uTasker/uTaskerSerialLoader.PDF

For the complete "out-of-the-box" Kinetis experience and faster time to market

:smileyinfo: Out-of-the-box support for 46 Kinetis boards and 10 IDEs (460 combinations from a single code source with no porting required)

[pidgeydoyle]

Hi Mark,

Thanks very much for your reply.

The reason I decided to go for the block swapping method is that it maintained a backup copy of code. Making it possible to revert to the known working application.

I'm not too concerned about wasting memory, my application is fairly basic and will fit easily within half the available memory with plenty of room for further improvements. It also seemed like it would be a very robust way to update remotely especially in the event of a power failure during flashing.

It also seems easy from a development point of view to be able to develop the system using the FRDM-K64 board rather than having to get prototype PCBs made with an SPI flash connected.

I suppose I was really looking for a really basic blueprint of how someone would go about developing for the block swapping method, I understand how the demo app works but I'm unsure how it would be implemented in my application. 

P

[mjbcswitzerland]

Peter

I agree that if you want to be able to swap between two SW versions the swap block is practical.

From an application point of view, loading the new SW in your case is straight-forward:

1 - receive it as binary or SREC or other format over the serial interface, saving it in the second Flash block (which has been erased beforehand). Now you have the alternative SW image as well as the one that you are are presently running.

2 - On command, or based on some input (eg a switch which selects application A or B), and assuming the requested appliation is not already selected, execute the swap command and reset. Now the alternative SW runs.

3 - The alternative SW must also support the same basic commands in order to be able to swap back to the original SW again.

I have the following solution (for Kinetis and Coldfires) which is a bit more complicated and uses external SPI Flash:

- An original application is loaded which makes a backup of itself in SPI Flash (since there is nothing there) - "present application" backup.

- The application loads new SW to the SPI Flash (eg via Ethernet)

- The BM loader (2k in size in the first Flash sector) exchanges this software to operational flash using fail-safe techniques

- The new application runs and can be commanded to restore the original SW in case of any issues with it in the course of operation

- If the new application runs for a period of 30 days without receiving a command to restore the previous version it makes a backup of itself - "present application" backup - so that it is now the "golden-version" and can be restored in case of an issue in the future with new updates.

This has been used in television broadcasting equipment where high up-time is critical as a 'panic' restore in case of any issues after an update and stores the backup in encrypted from. Therefore it is a bit compliated for typical usage, but is available as "standard" solution when required and SPI is available (6 SPI Flash types are supported at the moment).

Regards

Mark

[Hui_Ma]

Hello Peter,

If customer consider to use K64 product, it need to use a bootloader routine in K64 chip to load the new image to Flash upper block. The new firmware image also need to include the bootloader routine, otherwise the next round firmware update(after Flash swap) couldn't be realize.

Customer could refer Kinetis bootloader software about K64 bootloader. The Kinetis bootloader supports UART serial bootloader.

Customer also could download and refer Kinetis TFS Flash Driver software about Flash Swap application.

Wish it helps.

Have a great day,
Ma Hui

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[pidgeydoyle]

Hi Hui_Ma,

Thanks for your reply.

One of the benefits of this type of remote firmware update is that there is no requirement for a bootloader.

From the freescale Robust Over-the-Air Firmware Updates Using Program Flash Memory Swap on Kinetis Microcontrollers app note AN4533:

Advantages

• Ease of programming. Application always executes out of the lower block in the memory map.

• Power loss tolerant.

• No bootloader required. No delay to the start of the main application.

• Well suited for a multi-tasking OS. Minimal application downtime. In a multi-tasking system it is possible to continue to execute the main application tasks while background tasks are running to update the new copy of the application.

• Backup copy of code. Possible to revert to the known working application.

Best Regards,

Peter