Coldfire V2 devices and serial debuggers
Locked
Coldfire V2 devices and serial debuggers
 
|
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. [hidden email] Send a post to the list. [hidden email] Join the list. [hidden email] Join the list in digest mode. [hidden email] Leave the list. |
Re: 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>[hidden email] > Send a post to the list. [hidden email] Join the list. > [hidden email] Join the list in digest mode. > [hidden email] Leave the list. ------------------------------------------------------------ Tim Stoutamore, Principal Engineer Blunk Microsystems, LLC 6576 Leyland Park Drive San Jose, CA 95120-4558 Tel: 408/323-1758 [hidden email] www.blunkmicro.com ------------------------------------------------------------ --- [hidden email] Send a post to the list. [hidden email] Join the list. [hidden email] Join the list in digest mode. [hidden email] Leave the list. |
Re: Coldfire V2 devices and serial debuggers
|
|
In reply to this post by Harjit Singh-2
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 --- [hidden email] Send a post to the list. [hidden email] Join the list. [hidden email] Join the list in digest mode. [hidden email] Leave the list. |
Re: Coldfire V2 devices and serial debuggers
|
|
In reply to this post by Harjit Singh-2
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>[hidden email] > Send a post to the list. [hidden email] Join the list. > [hidden email] Join the list in digest mode. > [hidden email] Leave the list. [hidden email] Send a post to the list. [hidden email] Join the list. [hidden email] Join the list in digest mode. [hidden email] Leave the list. |
Re: Coldfire V2 devices and serial debuggers
|
|
In reply to this post by Harjit Singh-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 (406) 245-5002 ext 102 (406) 245-4889 (fax) WWW: http://www.link-comm.com MailTo:[hidden email] --- [hidden email] Send a post to the list. [hidden email] Join the list. [hidden email] Join the list in digest mode. [hidden email] Leave the list. |
RE: Coldfire V2 devices and serial debuggers
|
|
In reply to this post by Harjit Singh-2
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: [hidden email] Subject: Digest from [hidden email] To: [hidden email] Date: Wed, 11 Feb 2009 00:00:05 -0600 --Forwarded Message Attachment-- From: [hidden email] To: [hidden email] 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: [hidden email] To: [hidden email] Subject: Re: [ColdFire] Coldfire V2 devices and serial debuggers Hi Harjit, --Forwarded Message Attachment-- From: [hidden email] To: [hidden email] Date: Tue, 10 Feb 2009 20:26:44 +0100 Subject: Re: [ColdFire] Coldfire V2 devices and serial debuggers Harjit Singh wrote: --Forwarded Message Attachment-- Date: Tue, 10 Feb 2009 12:53:01 -0700 From: [hidden email] To: [hidden email] Subject: Re: [ColdFire] Coldfire V2 devices and serial debuggers Hi Harjit, Windows Live™: E-mail. Chat. Share. Get more ways to connect. See how it works. [hidden email] Send a post to the list. [hidden email] Join the list. [hidden email] Join the list in digest mode. [hidden email] Leave the list. |
Re: Coldfire V2 devices and serial debuggers
|
|
In reply to this post by Steve Strobel-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 --- [hidden email] Send a post to the list. [hidden email] Join the list. [hidden email] Join the list in digest mode. [hidden email] Leave the list. |
Re: Coldfire V2 devices and serial debuggers
|
|
In reply to this post by Harjit Singh-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 --- [hidden email] Send a post to the list. [hidden email] Join the list. [hidden email] Join the list in digest mode. [hidden email] Leave the list. |
Re: Coldfire V2 devices and serial debuggers
|
|
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 --- [hidden email] Send a post to the list. [hidden email] Join the list. [hidden email] Join the list in digest mode. [hidden email] Leave the list. |
«
Return to Coldfire
|
1 view|%1 views
| Free forum by Nabble | Edit this page |