MicroMonitor on K64FRDM...

[EdSutter]

For anyone that may be interested, I spent some time working on a version of MicroMonitor (http://www.umonfw.com) called uMon-M (uMon for MCUs) to run on these Cortex-M3/4 type devices.  Its basically a trimmed down version of MicroMonitor with networking and a basic flash file system that overlays a configured portion of the internal flash.  I have it running on the K64FRDM board (and a few others) if anyone is interested in trying it out, it would be great to get some folks using it and beating on it a bit.  The tarball uses some code from the SDK, and also includes a few example applications that demonstrate how a bootloader/application configuration could be set up.

Its still being "tuned", trying to cut it down in size as much as possible; but still maintain a core set of features useful in a bootloader environment.

Currently it builds for two different modes, primarily just for footprint size.  The small footprint supports a downloadable network node (ARP/ICMP/TFTP) and some configurability for bootup.  The larger footprint supports essentially the same stuff (with a lot of fat removed) that regular uMon supports.

There's a "getting started" document here: http://www.umonfw.com/docs/uMonM_GettingStarted_K64FRDM.pdf

If interested, reply to this or just download it and give it a shot.  I'd love to get some feedback on its usefulness in these types of systems.

Thanks,

Ed

[EdSutter]

My immediate goal for this is to help out someone that has been working on a K60 project for a few months now running with MQX.  They just recently were told they need to run with a bootloader so the application can be upgradeable over Ethernet.  The bootloader part (aside from trimming more fat) is in place, so now I have to take their Code Warrior-based application (note: I've never used CW) and adjust it to run on top of my bootloader.  Unlike most uMon applications, this will not share anything with the monitor, it will just take over the system once it starts up.  uMon can DHCP/TFTP the image directly into its destination flash space, and then jump to its entrypoint.

So, I'm guessing that all I need to do is adjust the memory map of the application and make sure they use a relocated vector table.  Are there any other issues I'm missing here?

[mjbcswitzerland]

HI Ed

There are a numbef of MQX projects using the uTasker serial loader (mainly for USB-MSD and and SD card loading but it also supports Ethernet loading).

Generally there is little difficulty:

- the link address must be set correcly and the vector table accordingly (either at the new 0x80 aligned Flash address or in SRAM)

- if your loader has started the watchdog make sure the application also triggers it (otherwise disable it with the option of allowing the application to re-configure it later)

- it may be worth configuring the clocks with the same code as the application uses (or at least set to the same operating frequency) since I don't think that the code that is used there handles unexpected cases and can hang.

- when the loader has used peripherals it is best to deinit them (just power them down) and expressly disable any interrupts that were used to ensure no difficulties when the application re-uses them.

- MQX based projects tend to be quite large in size so having a loader that is as small as possible helps to reduce the chance of running out of memory space later.

Regards

Mark

[EdSutter]

Thanks Mark,

Good points.

Regarding size, the goal for this is 32K for ARP/ICMP/DHCP/BOOTP/TFTP and flash operations.

I'm gettin' real close!  :-)

Ed

[mjbcswitzerland]

Ed

I have never had a request for TFTP based loading (FTP client is used in one project for firmware management and loading but this is not integrated in the serial loader itself).

Out of interest I configured with ARP/ICMP/DHCP/UDP/TFTP and BOOTP functionality, which gave 14k code size - this however uses a Flash file system (since the TFTP server works with it) which could be partly redundant - in the web server loader I remove the file system since it is possible to post the new SW using direct flashing routines as it only has this one function. To reduce the size further I would modify the TFTP server's memory interface to work with Flash memory directly (reducing general flexibility as it is not required for a single SW location in flash) - probably it would shave off about 2k but it is not easy to test quickly.

Don't forget to work with -Os so the compiler is doing its work too ;-)

Regards

Mark

[EdSutter]

Mark,

Wow, you've surely got your environment tightly tuned. I'll never see that size.

Good stuff!  I hit my 32K goal, so I'm good to go.  Thanks for the -Os tip.

I was using -O2, changed to -Os and it magically reduced my size by 4K.

Take care,

Ed

Just wanted to add a note here for anyone other than Mark & I reading this...

The uMon-M stuff is very informal, not intended as a product.  I mentioned it

here for anyone that wants to play around with it and maybe help me clean it

up a bit (as Mark has).  If you need something real and well tested, go see Mark!  :-)

[mjbcswitzerland]

Ed

I just read your document. I am surprised that the TFTP loader is so large - the uTasker project has ARP/ICMP/IP/TCP/HTTP web server interface loader which is 16k in size on the Kinetis devices. I would estimate TFTP to be around 10k (although not knowing what else may be packed in there).

The uTasker serial loader has SREC, USB-MSD, USB-HID (KBOOT compatible), (encrypted) SD-card and Ethernet web server loaders and works on all KL and K devices (when the required peripheral interface is available in the chip) and can be built with KDS, CW, Rowley, GCC, IAR, Keil, Atollic, CooCox or VisualStudio (for real-time simulation).

Have you considered dropping your code in to a task in there and making use of the integrated TCP/IP resouces, file systems, etc. as well as real-time simulation/development/debug capabilily since it would then add a uMon-M mode to it that will then be compatible with all the devices and IDEs?

Regards

Mark

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

[EdSutter]

Mark,

Good stuff!  Certainly a super-set of anything I've got.

I'm doing this as a personal learning experience on the Cortex-M family.

That's half the fun.  I wrote this boot environment years ago for larger embedded

systems, and wanted to see how much fat I could trim off it to fit these little guys.

At the moment, I don't have a project, just gonna continue trimming.  :-)

Thanks,

Ed