« Return to Thread: Coldfire V2 devices and serial debuggers

Re: Coldfire V2 devices and serial debuggers

by Chris Johns-2 :: Rate this Message:

Reply to Author | View in Thread

Harjit Singh wrote:

>
> Forgive my lack to astuteness with regards to how to respond to this
> list. I'm sure with your assistance I will figure it out soon.
>  
> Some more info.
>  
> I'm not using an RTOS and don't have really much of an OS. I boot, setup
> the HW and run my stuff. Most of my processing is done using state
> machines that are triggered by interrupts.
>  
> In the past, I used a CPU32 (68376) with (ten year old) SDS tools where
> I used their serial monitor. This allowed me to look at variables,
> single step code, etc. while the servo interrupt was running. The way I
> did this was by setting up the servo interrupt to run at a higher
> interrupt level and so when I broke into the monitor, it took over the
> PC but since it didn't block interrupts (since the servo interrupt level
> is higher, it will happily run while I'm poking around the debugger).
>  
> 95% of the time I want to look at variables. Occasionaly I want to step
> through code - this happens when I need to debug the state machines.
>
> I'm going to use a MC52223 device which has a BDM, serial (UART) and USB
> interfaces.
>  
> Tim, do you have TargetMon running with a serial port?
>  
> Oliver, I should clarify that I'm not too concerned about precise cycle
> times. My concern with BDM is that the tools I've read about, halt the
> CPU for hundreds of microseconds and that causes the servo loop to stop
> functioning and the motors do crazy things.
>  

The BDM protocol will support access to certain CPU resources while the
program is running. The Sourceforge tools provide an open source library of
code with calls that allow access to the BDM protocol. If BDM allows it the
BDM drivers and support libraries will also allow it. There are how-ever some
constraints that make what you want difficult with BDM. The main one is CPU
registers are not accessible when the processor is running. This means
variables held in registers will not be seen and the same goes for the PC so
now does the external host program know where the PC is and where to step next.

The BDM package on Sourceforge has a program called bdmctl that may go some
way to helping you. You should be able to run the processor and then dump memory.

A debugger stops the process, which for a system like yours is the processor,
so you have access to variables and registers in a known stable state. A
serial stub will allow you to do special things such as run an interrupt that
needs to run and so I see a serial monitor of some form being what you need.

I suggest you look for a GDB serial monitor stub for the Coldfire. This has
been done and they do exist. For example Netburner has had a closed source
stub for years. I have seen references to a stub in the Redboot monitor for
eCos, and GDB has a m68k-stub.c as its current example in GDB:

http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/m68k-stub.c?rev=1.4&cvsroot=src

You could take this file and adapt it to your needs and then GDB would be
available. If you need a hand send me an email. An open source serial stub
would be most welcome.

Regards
Chris
---
coldfire@...              Send a post to the list.
coldfire-join@...        Join the list.
coldfire-digest@...    Join the list in digest mode.
coldfire-leave@...     Leave the list.

 « Return to Thread: Coldfire V2 devices and serial debuggers