Programming MCF52212/52233 processor

[Lakshmi]

HI All,

We are currently using MCF52212 & MCF52233 processors in our product.

We are programming the processors using BDM interface (connected to USB port of the PC). It is not quite easy to program the processors at the customer site by opening the shield always to program the upgraded firmware versions.

We are currently using Client which communicates with these freescale boards through TCP/IP communication.

Is there a way to program the processors using Client through TCP/IP commucation, without any external BDM needed?

If the above is not possible, do we have any other option to achieve what we want?

Please get back ASAP

Thanks,

Lakshmi

[scifi]

---

Lakshmi wrote:

Is there a way to program the processors using Client through TCP/IP commucation, without any external BDM needed?

---

Yes, there is. The MCU can write to its own flash memory. The data for programming can come from any of its external interfaces, including Ethernet.

Implementing such functionality may require some non-trivial development effort.

[Lakshmi]

Hi,

Thanks for the reply.

As I mentioned, we have a Client which communicates with 52233 through TCP/IP interface.

We want to program .S19 file to 52233 processor using the TCP/IP interface. If that is possible, can you give me more details about where I can get additional information on this & what is the non-trivial development effort needed?

Thanks once again

[scifi]

Sorry, I cannot point you to additional information. Try searching for 'in-application programming' (IAP).

A number of different setups can be used to perform firmware updates in the field:

1) The traditional approach is to split the firmware into 2 parts: monitor and main application. The monitor is launched when a firmware update is required. It handles the update process, overwriting main application as needed. The monitor itself cannot be updated. This approach leads to simple flash memory partitioning: monitor flash area and main application flash area. Some code duplication may result: e.g. TCP/IP support would be contained in both monitor and main application.

2) The main application itself can be designed to be able to update itself. During the update process, the new firmware image has to be stored somewhere while the previous one is running. Once the new image is stored, some way of switching over to the new firmware image must be implemented (perhaps involving a small monitor program.) More memory is required than with previous method. And the switchover part can be tricky to implement.

Both approaches can be made fault-tolerant in the sense that a power supply failure during firmware update won't brick the device.

[TomE]

The "classic" starting point is to load something like u-boot onto the unit, and use it to load and update the application code.

U-boot traditionally supports PPC-based processors and boards, but it also supports two "Coldfire" boards:

http://git.denx.de/?p=u-boot/u-boot-coldfire.git

http://www.denx.de/wiki/view/U-Bootdoc/SupportedHardware

U-Boot is so complex and with so many supported features that unless you're using it to boot Linux (its main purpose) then it could be a lot bigger and more complicated than your Application code. It could almost "host and be the operating system for" your Application code.