1. Home
  2. Embedded Programming
  3. Cygwin environment Debugging Support for the BDM coldfire is not there with the GDB of Cygwin tool chain

Cygwin environment Debugging Support for the BDM coldfire is not there with the GDB of Cygwin tool chain

Hi Friends,

I am now trying to compile the Codwarrior code( MCF5272 processor ) and play with it. But there are some issues with debugging it. The hardware support for the BDM coldfire is not there with the GDB of Cygwin tool chain.

formatting link
GDB talks to the target through this tool and the P&E Micro BDM interface from the Cygwin Environment.

formatting link
This is another version, but this doesn't have the exact processor support through BDM.

Kindly let me know if there is any BDM coldfire support via Cygwin for debugging an RTOS application.

Further, with the help of google , i came across the following link :

-->

formatting link
which states as below :

One thing to be careful with is GDB. GDB needs to be altered a bit (patched) so that it will connect with the BDM connector to the target. This patch is usually a version or two behind the main GDB tree. So your best bet is to find the patch first, then get the appropriate version of GDB for that patch. In my case, GDB 6.2 was out, but I could only find the patch for 6.0. So I was stuck with GDB 6.0. The patch is at the Sourceforge BDM website.

But, i did not find any info w.r.t MCF5272 coldfire support. Kindly let me know if any of you have ideas / info / patch / document / help w.r.t this .

Tonnes of Thx in advans, Karthik Balaguru

Reply to
KBG
Loading thread data ...

Hello,

You could use the BDM tools from the sourceforge website

formatting link
We are using these tools for 6833x and Coldfire development in our company. Simply download the patches and an appropriate GDB version (See the supplied patches in the download) and you are ready. The patches also include support for the graphical insight debugger if you prefer working with a GUI.

Kind regards, Christian Walter

Reply to
Christian Walter

Hi Christian Walter,

Thx for your prompt reply. Does that have support for MCF5272 Coldfire Processor code based on cygwin environment ? I was unable to locate it there . Could you pls send me some link that point to the patch for using the BDM - GDB in cygwin environment for debugging with respect to MCF5272 coldfire processor.

Anyhow, i will give a good look onceagain into the supplied patches in the download section of

formatting link
. How did it escape from my eyes ??? ( Need to check my eye lens power ... hahaha !! )

Tonnes of Thx in advans, Karthik Balaguru

Christian Walter wrote:

Reply to
KBG

Hello,

Sorry - I did not read till then end of your message because it looked like it was finished after the two dashes. I see you have already found the sourceforge link so I would recommend the following steps:

  • Download the 1.3 version from the website.
  • Build them and check your target support by calling $ bdm-chk /dev/bdmcf{0,1,2,3} The values {0,1,2,3} depend on the parallel port you are using. Make sure these things work before continuing.
  • Download an appropriate GDB version
  • Apply the patches to the GDB version and build an m68k-bdm-elf target.
  • No you should be able to use the GDB. For a basic test I would recommend starting gdb and trying to connect to the target with: (gdb) target bdm /dev/bdmcf0 trying kernel driver: /dev/bdmcf0 ...

Note that for GDB to be actually useable you will need a target script to setup the SDRAM controllers and chip selects.

If you want to go with the GUI simply use Insight and apply the GDB and insight patches to it. You might also want to look at the patches page on the sourceforge website where I supplied patches for the Coldfire2 cores. I might also be worth trying the CVS version because it contains some fixes not in CVS.

Kind regards, Christian Walter

Reply to
Christian Walter

Hello,

I have not tested them with a MCF5272 target but I think it should be no problem at all. I am using it with a MCF5235 target right now. The standard registers which are accessible over the BDM are the same for all coldfires. A problem is when the BDM tools try to access a register which does not exist. What error message do you get with the standard distribution when you try the 'bdm-chk /dev/bdmcfx' command?

This was the reason why I rolled the coldfire2/coldfire2m patches which add support for the additional registers. Anyway it should be no problem to patch the bdm tools if you need special support (at least if you don't want to integrate the patches).

Kind regards, Christian Walter

Reply to
Christian Walter

Hi ,

I am looking into the

formatting link
info and i think, for MCF5272 we need to tweak things a bit as there is no readymade patch available as of now.

Meanwhile , I came across something interesting - BDI2000. But, i dont want to put my legs in all the directions and be inside some tight knots.

Before starting of with BDI2000, i need to know, if anyone of you have tried it here with MCF5272 and is it bug free & powerful than

formatting link
.

Which is powerful and very good to use ?

formatting link
or BDI2000 .

Is the BDI2000 working fine for Debugging MCF5272 processor via BDM through Cygwin environment ? Else i will be sticking to

formatting link
.

Need to decide upon one of the above.

Tonnes of Thx in advans, Karthik Balaguru

Christian Walter wrote:

Reply to
KBG

SNIP

We have used the BDI2000 with the MCF5272/5282 and it works quite well. It was used with an integrated GNU implementation sold by Microcross

formatting link

I highly recommend the Microcross Visual X-Tools. We use them on a number of projects with a variety of processors, both Coldfire and ARM. There GDB implementation works much better for us than Rowley's version.

DISCLAIMER: In all fairness I must say that we are a Microcross partner. That said, I stand by my above comments.

Scott

Reply to
Not Really Me

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.