software uploads via Ethernet/Internet

[amleng]

Is there any solution for MQX to update the FW through Ethernet/Internet?

[DavidS]

Hi Amleng,

Please review this post:

https://community.freescale.com/thread/102858

In general the MQX application cannot update itself without having 2x the flash to ping pong which to start/boot from.

Having a bootloader to handle the FW update is generally the solution and the link above points to several options.

Hope this helps.

Regards,

David

[trailman]

Hi,

I have posted some code to update MQX from itself. The trick was :

- to use the first half of the internal flash for the running code (no trick here; this is normal !!)

- to use the second half of the flash as a buffer (using a "buffer:" device driver) to temporarily store an update downloaded through FTP or TFTP (example with FTP : get update.S19 buffer: ) while the system is still up and running MQX. The image downloaded can be verified (checksum) to make sure it is OK.

- to use a little "update" command doing the real update (relocated and executed from RAM) doing the copy of this buffer to the first half of internal flash and resetting the board to restart on the new release.

Explainations are https://community.freescale.com/message/73480#73480

Last month, my application code size has exceeded the half flash size, so I updated the "buffer:" driver and the "update" command to use an external SPI flash as buffer, and I now have all the internal flash size available for application.

This works fine.

I have not yet posted the updated code with the SPI flash support.

[amleng]

Yor idea sound great. Would you please explain more about SPI version. Thanks

[trailman · Accepted solution]

If you want to update your MQX+application on fly, without the need for any external tool such as a BDM probe, you have the choice between these solutions :

- use a botloader : the bootloader is a minimal software stored in flash that is run first after each reset. By default its purpose is to boot your MQX+application also stored in flash (in the remaining space). When an update is needed, the user can stop at bootloader level (by pressing a key on serial console for example) and get a shell prompt from which a new MQX+application can be retrieved (from network for example) and burnt to flash overriting the current one.

The good point is that if power is removed while tne new image is update, the bootloader is still there and the update process can be done again to have a valid QX+application image. This is very safe.

However to do the update you need to physically connect to the local serial console, unless the bootloader allows a remote connection, and your application is down during this process

For this solution your can follow the link supplied by DavidS above.

- do without any bootloader and implement all the update software in your MQX+application. As your can not overrite the running image in flash, you need a buffer to store the new image while downloading; then once the image is in the buffer and has been fullly checked you run an update command that copy the buffer to the flash and reset the board.

The good point is that when your are downloading, your MQX+application is still running and you have all the MQX ressources available to download : FTP, TFTP, HTTP,... and can do that remotely connected to the board through a TELNET session (serial port console not mandatory).

The only drawback is that if the board is reset/powered-down while the final update command is running (takes few seconds) the board is dead with a broken software.

For this solution your can follow the linked I provided above.

Now when I speak about an external SPI flash for the second solution, this is to have all the internal flash available for the MQX+application image. The SPI flash is used as the buffer to store the downloaded image, and then this SPI flash is read-back by the update command copying its content to the internal flash. So you have to use the MQX SPI driver to write to the flash and have an update command supporting the read-back from this flash.

Without this external SPI flash, you have to use the second half of internal flash for the buffer, and then you only can use the first half of the internal flash for your MQX+application image. This is OK if your code is small enough but was not for me anymore.

My board has an MCF52259 (512Kbytes internal flash).

For the external SPI flash, I used an AT25DF041 (512KBytes).

Maybe I will post the modified buffer: driver and update command supporting this external SPI flash if some guys are interested.

[chandrasekarkan]

Hello Gilles

I am using a Kinetis K60DN512 MCU interfaced with external SPI flash.

I am able to get the binary file from a ftp server and store it in the SPI flash.

to copy firmware from SPI to non-active Flash bank and to execute the swap command sequence I referred to the following link

Re: Using flashx io_ioctl FLASH_IOCTL_SWAP_FLASH_AND_RESET for bootloader

The swap goes to update erase state, then i copy from SPI to flash and when reset, neither of my application is running.

I use my peMultilink debugger to recover the MCU later.

I am not running copy or swap commands from SRAM.... may be this could be the issue???....

Please help me further...

Thank you

[trailman]

Hi,

I don't know about the K60 flash, nor about the bootloader/ioctl you speak about.

In the post, I did it on a MCF52259 without bootloader, by copying the content of the external SPI flash (containing an update) to the internal flash (containing the image to run), without any swap mechanism (I only have one executable image in internal flash).

The only thing important is to have the code doing the copy running from RAM, because you can not execute some code from flash while you are updating it.

With the MCF52259, you can do it by simply copying this code from flash to RAM and run it from RAM. This is done in the code I posted here Building a relocatable C program that can be run out of SRAM in MQX but this code was my original code not using an external SPI flash (using second half of internal flash as update source to update the running image in the first half)

Here is an updated sample code copying from the external SPI flash to the internal flash and resetting at the end to restart on the new image. I hope this will help you.

[chandrasekarkan]

Hi

      I have got it firmware update working on my custom board...

Mistake was, when downloading my 1024 byte chunks of bin from FTP server, the sector(4kB) erase in my writeSPI

function was erasing the previous chunks in the sector.

     The flashx BSP - addition from this link ->https://community.freescale.com/message/315330#315330

helped me achieve this straight away.

     Thank you so much Gilles, your references have kept me trying this.... I will further ruggedize my code

with this above attachment...

[c0170]

Hi amleng,

There is bootloader example for some Freescale devices. The example uses TFPT to download the firmware. You have not provided what board are you using.

Regards,

MartinK