topic Re: Debugger/Monitor integration in ColdFire/68K Microcontrollers and Processors

Debugger/Monitor integration

michaelmeier — Wed, 09 Mar 2016 08:40:56 GMT

(Disclaimer: I have already asked this in the CodeWarrior section, but have been asked to carry my question over to this space. Link below.)

I am developing software for Coldfire Processors with CodeWarrior 10.3 and 10.5. During development, I cannot rely on e.g. USB TAP for debugging, as I often have no physical access to the system with the ColdFire processor. However, I would still like to be able to use the CodeWarrior debugger functionality.

On the Coldfire, we are running a ROM Monitor and we can speak with the ROM Monitor over a network interface. Now I am looking for a way to integrate the ROM Monitor into CodeWarrior as a new connection type. I know that this was possible with older (Metrowerks) CodeWarrior versions.

The original question was:

What interface would I use to accomplish this?

To elaborate this a bit, we are currently thiking about a number of ways to achieve debugging access without BDM:

1. [CW [CW Debugger]] <- CCS protocol over TCP -> [our own implementation of a CCS server] <- monitor protocol -> [[Monitor] Coldfire]

We have not been able to obtain information on the CCS protocol, so this route seems improbable.

2. [CW [CW Debugger]] <- GDI -> [our own GDI plugin] <- monitor protocol -> [[Monitor] Coldfire]

We have not been able to obtain information on the GDI (Generic Debug Instrument, of Metrowerks fame) interface, so this route seems improbable.

3. [CW [CW Debugger]] <- App TRK protocol -> [our own implementation of an App TRK server] <- monitor protocol -> [[Monitor] Coldfire]

The MetroTRK (of Metrowerks fame) protocol is no longer supported. App TRK is still supported by Codewarrior, but nominally only for applications running on Linux. This route is improbable, but maybe less so.

4. [m68k-gdb] <- GDB Remote Serial Protocol over TCP -> [our own GDB server] <- monitor protocol -> [[Monitor] Coldfire]

This route is definitely possible. However: a.) We're stepping outside Codewarrior: Less integrated, more development environments and b.) Without actually having it implemented, we're not sure how well GDB deals with the proprietary Codewarrior Compiler's ELF files.

Do you have more information on any of the routes, experiences with these approaches or other, workable ideas?

Original thread:

ROM Monitor for Debugger Access

Re: Debugger/Monitor integration

TomE — Fri, 11 Mar 2016 12:40:09 GMT

Eclipse/GCC/GDB might be possible, but you'd have to ditch CodeWarrior.

I can't talk. We're running a "bare metal polling loop OS" and debugging with print statements or blinking LEDs. The USB debug pod doesn't like our watchdog setup so we can't even get reliable single-stepping. And that's with command-line GDB when it does work. Compile under Linux with command-line/Makefile GCC, edit with VI or with MS Visual Studio on a Windows VM.

You didn't say which model Coldfire chip or what OS you're running. If it is an MCF54 then running Linux native on it, and debugging "user programs" on it over Telnet or SSH might be possible. Are you using MQX? Does it have any debugging support that might help you?

The other possibility is to choose the manufacture, processor chip and operating system based on the debug support provided by that chip maker or OS provider. Freescale are pushing ARM now over 68k. Maybe some of them might support your requirements? How much life is left in the model of MCF chip you're using? Many of them are approaching or have passed EOL, and there are a lot at "not recommended for new designs".

Tom

Re: Debugger/Monitor integration

michaelmeier — Mon, 21 Mar 2016 10:21:52 GMT

We are using MCF54418 parts. We are running MQX on the processor. The words "BDM" and "monitor" are to be found in the MQX source code. MQX seems to have some configuration options around cache invalidation to help when a debug monitor/BDM modifies data, or even worse, code behind the OS' back. I did not find any information about a monitor being built into MQX.

I believe that the debugging situation would be clearly better under Linux as we'd be able to run a stock gdbserver over a custom communications line or the AppTRK server provided by Freescale.

Eclipse/GCC/GDB might be possible, but you'd have to ditch CodeWarrior.

If we're lucky, we might be able to use CodeWarrior to write and compile our programs and then use GDB to debug. I have not had the time to write a lot of code, but I have done a preliminary experiment: I load an .elf generated by CodeWarrior into gdb. gdb does not complain and knows about the symbols and the source code. In other words: there is hope :smileywink:

The other possibility is to choose the manufacture, processor chip and operating system based on the debug support provided by that chip maker or OS provider. Freescale are pushing ARM now over 68k.

I like the way you are thinking! :smileygrin: I believe the situation is nicer with the ARM chips as most manufacterers provide an IDE built around GCC/gdb. Especially gdb has documented interfaces suited and known to mere mortals.

Unfortunately we have the MCF54418 in a product which has hit the market a year ago and we plan to sell it for the coming years.

How much life is left in the model of MCF chip you're using?

Freescale/NXP will sell us the chip for another 10 years. However I have gathered from Freescale representatives and also from my own experience that support on the Coldfire line is pretty line. They seem to have moved their talent toward their ARM solutions. As we plan to use the processor for the coming years, we are looking to make our debugging situation more agreeable and productive.