MQX on a non-Codewarrior IDE, BDM vs JTAG and custom BSPs

[DiBosco]

Hi folks,

I'm investigating doing a project that needs an OS and am looking at a V1 Coldfire and an ARM Cortex. In some ways MQX looks like a nice OS, but I can't use Codewarrior. Codesourcery are claiming it's possible to develop MQX with that, but then I supose they might say that anyway. Does anyone have any experience of using MQX with something other than Codewarrior? Is it a bad idea?

Are there companies about who might do a Codesourcery port  for us?

I could use a Cortex to do the project and in some ways that is a better solution as I have ARM tools that work on my host OS and it has JTAG rather than BDM. (The only drawback is price - the Coldfire wins there.) My experience with BDM is that it is a *lot* slower than JTAG and that uploading many tens of k of code to the processor will be like pulling teeth with something as slow as BDM. Does anyone have any input on this please? 

Finally, if we did take the Coldfire path,  does anyone know how difficult is for a JM128 custom board to have MQX ported to it. On the basis that there are no extra drivers needed for different hardware and that with the memory all being on-board, is it safe to assume it really is just a case of getting an existing port for a JM128 and we'd be able to start writing code? 

Many thaks for any help, would be most appreciated. 

[jbezem]

Do re-read the license for your MQX. IIRC the license explicitly forbids targetting a not-supported CF variant; not sure what, if anything, it says about using a different toolchain.

If your needs are not covered by the FSL license, you may need to talk to Embedded Access, the authors of MQX.

HTH,

Johan

[DiBosco]

Thanks for the reply, Johan.

Interesting, it hadn't even occured to me that it was't ported for JM devices as my customer seemed to have already looked into that. Having had a chat with someone at FreeRTOS, he was saying MQX is too heavy to run on the V1 cores properly anyway.

It's looking more like FreeRTOS is the way to go! 

Message Edited by DiBosco on 2009-07-06 02:16 PM

[DavidS]

Hi DiBosco,

Just a few comments and observations.

In general MQX is very scaleable.  So on large memory foot print device it is very full featured.  On V1 it is very restricted features but yet is able to run on V1.

Currently FSL MQX is ported to MCF51CN128 (a V1 with Ethernet) and as the year passes, many more V1's will be supported.

IAR is an alternate tool solution.  CodeSourcery/GNU tools will work but haven't been integrated to fully support FSL MQX.

Good comment already mentioned.... FSL MQX can only be used on Freescale silicon.

BDM is actually very fast interface.  It usually is the hardware tool used that determines the speed.  Most people like "cheap" solution which has slower bandwidth.  Green Hills hardware very fast.

Last comment, FSL MQX has inherent multiprocessor and distributed processor communications capability using the IPC (Inter-processor Communication) module.  This feature hasn't been officially turned on in the FSL MQX port but will be shortly.  IPC makes additional features in system as easy as adding a V1 to a design and IPC'ing to get results (ex: ADC) or bit bang.

Best Regards,

David

[DiBosco]

Hi David,

Thanks for the reply, a few interesting points there. 

I'd be interested to see a fast BDM in action as the P&E ones I've seen on, for example, an HCS12 really have been very slow. I would think that a JTAG interface is always going to many times faster as it's a synchronous system with data in and out, not one async bidirectional signal.  (It's the same with Atmel's tools, JTAG is really fast, oneWIRE debug is awful.) I'll look into what's avaiable with Codesourcery in terms of interfaces, but I've a feeling our definitions of fast are a little different. ;~) 

The issue of Codesourcery leads me on to IAR. I wouldn't touch IAR in general as their support I have found severely lacking in the past, but that aside, it doesn't run on my host OS anyway! 

On the subject of scalability that's encouraging to hear, I don't think we need much in the way of functionality really (PWMs, UARTS, timers, GPIO and CAN essentially). The customer wants to upgrade via a USB stick, but having thought about this, I can't see how that's feasible on this type of OS and small micro.   

I didn't mean to indicate this would be run on a non Freescale micro, sorry if I gave that impression.

All other things aside, my customer  wants to start this straight away, so if MQX isn't available on the JM for a while, this again points away from MQX.

Many thanks for your post, it's greatly appreciated. 

Rob

[DavidS]

Hi DiBosco,

We have a preliminary appnote for doing USB bootloader with JM family and ColdFire V2 devices.

Here is a copy of that.  When it is formally reviewed the appnote and software will get posted.

Regards,

David

http://www.freescale.com/files/community_files/MQXGEN/FSL_USB_MSD_Bootloader_pdf.pdf

Message Edited by t.dowe on 2009-08-27 02:54 PM

[DiBosco]

Hi David,

Thanks for that, I'd like to clarify a couple of points if I may:

1. I assume that this bootloader is not part of the OS.  ie You would boot into this as a run-to-complete program which ran completely out of the bootloader section of flash?

2. Is this using the controller as a USB device and connecting to a PC (which acts as a host?).

What the customer originally asked for was to plug a USB stick into the OTG port, have the Coldfire act as the host, and to update the software from the flash stick. I assume that would mean you'd neat FAT file system and USB host capability in a (4k IIRC) boot sector which would seem unlikely to me. 

Many thanks.

Rob

[DavidS]

Sorry Rob...was on vacation for a bit and upon return somehow missed your reply.  I apologize.

A1) Bootloader is separate "master" application that runs at bootup and something has to determine whether it remains in the bootloader or jumps to the application/OS.

A2) When connected to the PC and in the bootloader mode, the PC is host and the ColdFire OTG USB will be a device.  It will enumerate as a mass storage device.  On the PC you just open the folder to the mass storage device and drag-n-drop your s-record file to be flashed.

The customer original desire of pluging in USB stick and having firmware updated currently isn't supported by FSL.  There are 3rd parties that do have this.  This method uses roughly 12KB flash and 4KB ram.

Regards,

David

[DiBosco]

Bump!

A shameless bump on this one.

[JWW]

Rob,

Couple of items to add to the discussion.

BDM is a term that we all use somewhat interchangeably.  On ColdFire V2 through V4 we offer a high speed debug interface that uses the same pincount as a JTAG interface.  Our 1-wire style debug is targeted at small pincount devices where JTAG has typically been less desirable.  On our V2 MCUs you can get the speed that you desire...  V1, S08, and S12 are as you described...typically slower than some JTAG based implementations.  Just wanted to give you heads up that we have two variants in the family.  Much like the ARM JTAG and 1-wire implementation variations.

As for software..

I have seen some good examples and use cases where updating of the JM family over USB is quite doable... So if you need that feature I wouldn't discount the use case. 

As for various software options.  This is more for the members that might be reading this thread. As David pointed out, we are planning a serious of V1 MQX releases throughout 2009-2010.  The JM family is on that list.  But in the mean time we do have several partners and a variety of free software packages to help you get your job done.  And I have to say.. The FreeRTOS guys have been great.  They provide a great product.

We watch the forums frequently and look for needs from our customer base.  So if you have a MQX need, features, timeframe... Let us know.  We try to listen.. 

One last item.. If your host system is linux... We do offer a Codewarrior edition for linux..  It is really intended for developers that are trying to do linux development on linux hosted machines.  But since I've seen this question about using GCC on MQX, it might be of merit for us to investigate Codewarrior for Linux Hosted.

If I learn anything I'll post back to the forum.

Hope your project goes well.  Let us know if we can help.

Cheers,

JWW

[DiBosco]

Hi  JWW,

I did understand the difference bwtween BDM and JTAG. I have to use a V1 core hence it has to be BDM I'm looking at. I would happily spend more money for a faster device if it improved my upload speed! 

With the USB update, would that actually work with a little run-to-complete program in a boot sector rather than runnnig from the OS? Surely, if you wanted to doit with MQX you would need to store the new image in local external flash as it was downloaded and then have a boot sector program that copied it from external flash to internal. Or am I missing something?

I did have a play with the Linux version of Codewarrior a while back. I have this vague memory that it would only run on a very limited number of distributions or something like that. Memory's a bit hazy on it now! Any way up, it would splendid to have more apps ported to Linux!

It would appear that in terms of features you do have all that is needed on MQX; other than a port for the JM128!

Many thanks for taking the time to reply. 

Rob