Using MQX OS image with two binaries

[renjithvamanan]

Hi All

In our system we are using K60 CPU with MQX (BSP PSP).

We have two firmware images in the internal flash one actual and the other a factory image, both running on MQX.

Currently the MQX code is included in both the images which is redundant and thus wasting the precious internal memory in that sense.

Is there any way of build to make MQX image common to both these images and share?

Hope my requirement is clear.

Thanks,

Renjith

[markschuck]

Hi Renjith,

As far as i know there is no easy solution. Even if you were to put the effort in, you'd be loosing a significant advantage: you would no longer be able to update the core OS. What if new application features require new features in MQX? Or a critical issue in your OS configuration and setup is found to be faulty, but the error doesn't show up until you are using a new build of your application? Also, are you absolutely certain that code size is an issue for you? If so, invest in a good optimizing compiler and turn on full optimizations (IAR is excellent IMHO) then see if you really are code size limited. Also it may be possible to simplify your factory image so that it only provides update functionality rather than a fully functional system.

In my latest project with a K22 we felt we needed to guarantee we would be able to use the full amount of internal storage for future firmware updates, so we built a small bare bones boot-loader that could read from an external SPI flash (~1MB). We then stored our factory image there, along with a diagnostic image and our firmware updates. We use an external sequence that can force the boot-loader to revert to the factory image. During a firmware update the full update is transferred to the SPI flash and then the MCU is restarted, the boot-loader detects this update and erases the rest of the internal flash and loads the new image.

The advantage of this system is that the boot-loader is trivial and easy to validate. The factory image is always there to be reverted. we also have an easy way to load up a diagnostic image that can be used to diagnose hardware failures/faults. the only downside is the cost of the external SPI flash, but we've found that is well worth the 1 $ in small quantities (and even cheaper once the quantities ramp up...). No risk that the factory MQX image will run into compatibility problems with our future firmware updates.

In the past with 16 kB of internal flash and no OS we've also used a boot-loader + application. The application would use services from the boot-loader that were provided by a jump table that was embedded in the boot-loader (an array of function pointers). This way we were able to re-use code that was needed in both parts. As i said before, this still has the drawback that you can't update the shared components (unless you're willing to risk bricking units in the field...) You might be able to do something similar, but i don't think it would be worth the effort/risk

Cheers,

Mark

[renjithvamanan]

Hi Mark

Sorry for the delay in reply.

Thanks for your suggestions also.

I understand that with giving provision to share MQX between factory and actual images will limit the OS update capabilities in future.

But in our design we have considered the update of factory image while running the actual image, though this is meant only for critical updates(I understand the risk involved in this).

Currently we are using the Freescale compiler coming along with the Code Warrior, with full optimization ON, not sure whether it is as optimized as IAR.

The available internal flash is 1MB and we have allocated 724K for actual image and the rest for Boot loader and factory image.

Factory image only have the capability to update via USB and over the cloud, no other application features,

When I looked int the map files,  currently MQX (BSP, PSP, MFS, USBH etc) takes up to 100KB, which is 100KB X 2 in our case for both factory and actual images,

which is 20% of the total available program memory.

In my latest project with a K22 we felt we needed to guarantee we would be able to use the full amount of internal storage for future firmware updates, so we built a small bare bones boot-loader that could read from an external SPI flash (~1MB).

We also have an external SPI flash in our system. But writing and getting the firmware images in SPI flash won't make the update procedure slow a bit ?

I understand the difficulties, but do you thinks that there is a way to extract the MQX related things from actual and factory firmware and if it is placed to a common location,

both the images can share it. I think I may have to play with Linker settings but any idea how to do this exactly with Freescale CPUs?

Thanks,

Renjith