Coldfire V2 devices and serial debuggers

[Harjit Singh-2]

Some parts of this message have been removed. Learn more about Nabble's security policy.

Has anyone got a serial debugger running on a Coldfire V2 MCF52xxx device?
 
A while back I read that dBug supports the GDB protocol and dBug is a serial debugger. But all posts I have seen, seem to be about using a BDM based debugger.
 
The reason a serial debugger is prefered to a BDM based debugger is that I'm doing some robotics work and I can make the servo code run at a higher interrupt level than the serial debugger and this will allow me to debug code with servos running.
 
BDM is too intrusive and it will cause the servos to go nuts.
 
The CF debug docs say that BDM theoretically will steal cycles but everything I have read says tha the BDM debuggers halt the CPU...
 
Thanks in advance.
Harjit

---

Windows Live™: Keep your life in sync. See how it works. 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.

[Tim Stoutamore]

Hi Harjit,

 > Has anyone got a serial debugger running on a Coldfire V2 MCF52xxx
 > device?

Blunk's TargetTools includes a debug monitor, TargetMon, that connects
to the debugger (Insight/GDB) via Ethernet.

http://www.blunkmicro.com/tools-cf.htm

Currently, when a breakpoint hits, all tasks are stopped and only the
debug monitor runs, in polled mode with interrupts masked and still
communicating over TCP/IP, but we've had this running in an alternate
mode that just suspends the task that hit the breakpoint and lets other
tasks continue running.

We've had other requests from this, from customers doing motor control
as you are, and will be productizing this mode. If you are interested
in trying our software, we can supply this mode for you.

Best regards,
Tim

Harjit Singh wrote:

> Has anyone got a serial debugger running on a Coldfire V2 MCF52xxx device?
>  
> A while back I read that dBug supports the GDB protocol and dBug is a
> serial debugger. But all posts I have seen, seem to be about using a BDM
> based debugger.
>  
> The reason a serial debugger is prefered to a BDM based debugger is that
> I'm doing some robotics work and I can make the servo code run at a
> higher interrupt level than the serial debugger and this will allow me
> to debug code with servos running.
>  
> BDM is too intrusive and it will cause the servos to go nuts.
>  
> The CF debug docs say that BDM theoretically will steal cycles but
> everything I have read says tha the BDM debuggers halt the CPU...
>  
> Thanks in advance.
> Harjit
>
> ------------------------------------------------------------------------
> Windows Live™: Keep your life in sync. See how it works.
> <http://windowslive.com/howitworks?ocid=TXT_TAGLM_WL_t1_allup_howitworks_022009>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.

------------------------------------------------------------
Tim Stoutamore, Principal Engineer
Blunk Microsystems, LLC
6576 Leyland Park Drive
San Jose, CA 95120-4558
Tel: [phone]
stout@...
www.blunkmicro.com
------------------------------------------------------------
---
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.

[Oliver Betz]

Harjit Singh wrote:

[...]

> The reason a serial debugger is prefered to a BDM based debugger is
> that I'm doing some robotics work and I can make the servo code run
> at a higher interrupt level than the serial debugger and this will
> allow me to debug code with servos running.
>
> BDM is too intrusive and it will cause the servos to go nuts.

In most cases, a serial debugger will have more impact.

Do you want single step debugging of one task while the interrupt
service routine is still running? This might indeed be harder.

If you only want to observe or maniplate variables during program
execution, BDM is likely the better way.

> The CF debug docs say that BDM theoretically will steal cycles but
> everything I have read says tha the BDM debuggers halt the CPU...

Coldfire V2 BDM is indeed more intrusive than the HC12 BDM is.
Accessing memory stalls the pipeline, causing several cycles delay. I
couldn't get Freescale giving me official numbers, but my
measurements showed me that 4..6 cycles for every memory access are
likely.

You will probably see such delays also when using DMA transfers.

With architectures like the Coldfire V2, you shouldn't rely on
precise cycle by cycle instruction timing unless you know very well
what happens.

Oliver
--
Oliver Betz, Muenchen

---
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.

[Matt Waddel]

Hi Harjit,

Is this a platform that's running uClinux like M52277?  If it is, you can run
gdbserver/gdb via a serial connection.

Best regards,
Matt

Harjit Singh wrote:

> Has anyone got a serial debugger running on a Coldfire V2 MCF52xxx device?
>  
> A while back I read that dBug supports the GDB protocol and dBug is a
> serial debugger. But all posts I have seen, seem to be about using a BDM
> based debugger.
>  
> The reason a serial debugger is prefered to a BDM based debugger is that
> I'm doing some robotics work and I can make the servo code run at a
> higher interrupt level than the serial debugger and this will allow me
> to debug code with servos running.
>  
> BDM is too intrusive and it will cause the servos to go nuts.
>  
> The CF debug docs say that BDM theoretically will steal cycles but
> everything I have read says tha the BDM debuggers halt the CPU...
>  
> Thanks in advance.
> Harjit
>
> ------------------------------------------------------------------------
> Windows Live™: Keep your life in sync. See how it works.
> <http://windowslive.com/howitworks?ocid=TXT_TAGLM_WL_t1_allup_howitworks_022009>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.

---
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.

[Steve Strobel-2]

At 11:09 PM 2/9/2009, you wrote:

>Has anyone got a serial debugger running on a Coldfire V2 MCF52xxx device?
>
>A while back I read that dBug supports the GDB protocol and dBug is
>a serial debugger. But all posts I have seen, seem to be about using
>a BDM based debugger.
>
>The reason a serial debugger is prefered to a BDM based debugger is
>that I'm doing some robotics work and I can make the servo code run
>at a higher interrupt level than the serial debugger and this will
>allow me to debug code with servos running.
>
>BDM is too intrusive and it will cause the servos to go nuts.
>
>The CF debug docs say that BDM theoretically will steal cycles but
>everything I have read says tha the BDM debuggers halt the CPU...
>
>Thanks in advance.
>Harjit

My experience with the Coldfire BDM debugger is the same as
yours.  They way I used it, I don't think it ever did cycle
stealing.  That is probably due to the debugger software and drivers
rather than an inherent limitation of the BDM interface or hardware.

At one time I got GDB to work over a network connection to a Coldfire
running RTEMS.  As I recall, you could stop one tread while allowing
others to run, which was very helpful for troubleshooting some
problems, but did require the system to start up at least enough to
get the network going before debugging was possible.  I think that
Till Straumann provided the original code, possibly as part of cexp
(which I never used).  You could search the RTEMS mailing list
archive for more info.

You might also find something useful in the BDM project on
SourceForge.  I found a comment in an old mailing list post from
Chris Johns that says, "If you need BDM debugging support the BDM
project on SF has a remote gdb server in CVS that I am still testing.
It works with the rtems-4.9 debugger.".  I don't know if it will work
independently of RTEMS or not.

Steve


---
Steve Strobel
Link Communications, Inc.
1035 Cerise Rd
Billings, MT 59101-7378
[phone] ext 102
[phone] (fax)
WWW: http://www.link-comm.com
MailTo:steve.strobel@...

---
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.

[Harjit Singh-2]

Some parts of this message have been removed. Learn more about Nabble's security policy.

X-SpamDetect-Info: ------------- Start ASpam results ---------------
X-SpamDetect-Info: This message may be spam. This message BODY has been altered to show you the spam information
X-SpamDetect: *******: 7.000000 From3consonants=0.3, SpamUrl=4.1, Accept Orbs.0, X-Verify-SMTP present=0.6, Aspam=3.0
X-SpamDetect-Info: ------------- End ASpam results -----------------

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.
 
Thanks,
Harjit

---

From: coldfire@...
Subject: Digest from coldfire@...
To: zeetahhs@...
Date: Wed, 11 Feb 2009 00:00:05 -0600



--Forwarded Message Attachment--
From: zeetahhs@...
To: coldfire@...
Subject: [ColdFire] Coldfire V2 devices and serial debuggers
Date: Mon, 9 Feb 2009 22:09:54 -0800

Has anyone got a serial debugger running on a Coldfire V2 MCF52xxx device?
 
A while back I read that dBug supports the GDB protocol and dBug is a serial debugger. But all posts I have seen, seem to be about using a BDM based debugger.
 
The reason a serial debugger is prefered to a BDM based debugger is that I'm doing some robotics work and I can make the servo code run at a higher interrupt level than the serial debugger and this will allow me to debug code with servos running.
 
BDM is too intrusive and it will cause the servos to go nuts.
 
The CF debug docs say that BDM theoretically will steal cycles but everything I have read says tha the BDM debuggers halt the CPU...
 
Thanks in advance.
Harjit

---

Windows Live™: Keep your life in sync. See how it works..

--Forwarded Message Attachment--
Date: Tue, 10 Feb 2009 11:06:49 -0800
From: stout@...
To: coldfire@...
Subject: Re: [ColdFire] Coldfire V2 devices and serial debuggers

Hi Harjit,
 
 > Has anyone got a serial debugger running on a Coldfire V2 MCF52xxx
 > device?
 
Blunk's TargetTools includes a debug monitor, TargetMon, that connects
to the debugger (Insight/GDB) via Ethernet.
 
http://www.blunkmicro.com/tools-cf.htm
 
Currently, when a breakpoint hits, all tasks are stopped and only the
debug monitor runs, in polled mode with interrupts masked and still
communicating over TCP/IP, but we've had this running in an alternate
mode that just suspends the task that hit the breakpoint and lets other
tasks continue running.
 
We've had other requests from this, from customers doing motor control
as you are, and will be productizing this mode. If you are interested
in trying our software, we can supply this mode for you.
 
Best regards,
Tim
 
Harjit Singh wrote:

> Has anyone got a serial debugger running on a Coldfire V2 MCF52xxx device?
>  
> A while back I read that dBug supports the GDB protocol and dBug is a 
> serial debugger. But all posts I have seen, seem to be about using a BDM 
> based debugger.
>  
> The reason a serial debugger is prefered to a BDM based debugger is that 
> I'm doing some robotics work and I can make the servo code run at a 
> higher interrupt level than the serial debugger and this will allow me 
> to debug code with servos running.
>  
> BDM is too intrusive and it will cause the servos to go nuts.
>  
> The CF debug docs say that BDM theoretically will steal cycles but 
> everything I have read says tha the BDM debuggers halt the CPU...
>  
> Thanks in advance.
> Harjit
> 
> ------------------------------------------------------------------------
> Windows Live™: Keep your life in sync. See how it works. 
> <http://windowslive.com/howitworks?ocid=TXT_TAGLM_WL_t1_allup_howitworks_022009>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.
 
------------------------------------------------------------
Tim Stoutamore, Principal Engineer
Blunk Microsystems, LLC
6576 Leyland Park Drive
San Jose, CA 95120-4558
Tel: [phone]
stout@...
www.blunkmicro.com
------------------------------------------------------------

--Forwarded Message Attachment--
From: list_ob@...
To: coldfire@...
Date: Tue, 10 Feb 2009 20:26:44 +0100
Subject: Re: [ColdFire] Coldfire V2 devices and serial debuggers

Harjit Singh wrote:
 
[...]
 
> The reason a serial debugger is prefered to a BDM based debugger is 
> that I'm doing some robotics work and I can make the servo code run 
> at a higher interrupt level than the serial debugger and this will 
> allow me to debug code with servos running.
> 
> BDM is too intrusive and it will cause the servos to go nuts.
 
In most cases, a serial debugger will have more impact.
 
Do you want single step debugging of one task while the interrupt 
service routine is still running? This might indeed be harder.
 
If you only want to observe or maniplate variables during program 
execution, BDM is likely the better way.
 
> The CF debug docs say that BDM theoretically will steal cycles but 
> everything I have read says tha the BDM debuggers halt the CPU....
 
Coldfire V2 BDM is indeed more intrusive than the HC12 BDM is. 
Accessing memory stalls the pipeline, causing several cycles delay. I 
couldn't get Freescale giving me official numbers, but my 
measurements showed me that 4..6 cycles for every memory access are 
likely.
 
You will probably see such delays also when using DMA transfers.
 
With architectures like the Coldfire V2, you shouldn't rely on 
precise cycle by cycle instruction timing unless you know very well 
what happens.
 
Oliver
-- 
Oliver Betz, Muenchen
 

--Forwarded Message Attachment--
Date: Tue, 10 Feb 2009 12:53:01 -0700
From: Matt.Waddel@...
To: coldfire@...
Subject: Re: [ColdFire] Coldfire V2 devices and serial debuggers

Hi Harjit,
 
Is this a platform that's running uClinux like M52277?  If it is, you can run
gdbserver/gdb via a serial connection.
 
Best regards,
Matt
 
Harjit Singh wrote:

> Has anyone got a serial debugger running on a Coldfire V2 MCF52xxx device?
>  
> A while back I read that dBug supports the GDB protocol and dBug is a 
> serial debugger. But all posts I have seen, seem to be about using a BDM 
> based debugger.
>  
> The reason a serial debugger is prefered to a BDM based debugger is that 
> I'm doing some robotics work and I can make the servo code run at a 
> higher interrupt level than the serial debugger and this will allow me 
> to debug code with servos running.
>  
> BDM is too intrusive and it will cause the servos to go nuts.
>  
> The CF debug docs say that BDM theoretically will steal cycles but 
> everything I have read says tha the BDM debuggers halt the CPU...
>  
> Thanks in advance.
> Harjit
> 
> ------------------------------------------------------------------------
> Windows Live™: Keep your life in sync. See how it works. 
> <http://windowslive.com/howitworks?ocid=TXT_TAGLM_WL_t1_allup_howitworks_022009>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.

---

Windows Live™: E-mail. Chat. Share. Get more ways to connect. See how it works. 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.

[Chris Johns-2]

Steve Strobel wrote:
>
> You might also find something useful in the BDM project on SourceForge.  
> I found a comment in an old mailing list post from Chris Johns that
> says, "If you need BDM debugging support the BDM project on SF has a
> remote gdb server in CVS that I am still testing. It works with the
> rtems-4.9 debugger.".  I don't know if it will work independently of
> RTEMS or not.
>

It should work with any GDB based on the FSF sources. The gdb server is nice
and stable.

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.

[Chris Johns-2]

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.

[Oliver Betz]

Chris Johns wrote:

[...]

>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.

As long as we talk about watching a running program, this will apply
to a serial debugger as well - a serial debugger won't show local
variables on stack or in registers of a running application.

Just peeking global or static variables via Coldfire V2 BDM has
minimal impact (a small number of CPU cycles for each access). With a
serial debugger, you could control _when_ the CPU is interrupted, but
in total the handling would take longer => more load.

And you have better control over the CPU, BDM doesn't need a
bootloader etc. If your application disables interrupts, you might be
out of luck with a serial debugger.

As I wrote, if someone needs single step debugging of one task while
an interrupt service routine is still running, a good serial debugger
might be better. A bad debugger might crash also if interrupts remain
enabled during single step etc.

If you are willing to spend some money, you get very nice BDM
debuggers saving a lot of time.

Be aware that there might be BDM debuggers _not_ allowing realtime
variable watch but indeed halting the CPU for hundreds of
microseconds. I heared about Codeworrier doing so, but I didn't test
it myself.

Oliver

---
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.