GDB and Dragonball EZ.

• Messages sorted by:[ date ][ thread ][ subject ][ author ]

Hi David,

I think you will get a much better response from the GDB gurus on the gdb mailing
lists.  Visit http://sourceware.cygnus.com and click on the mailing list link.
Sign up for the gdb list(s).

I think you will find that GDB does support the hardware breakpoints on a lot of
CPUs, and I'm sure (not 100%) that the 683xx series does support it.

The other option you have with regards to communicating with the CPU is the BDM
interface.  Does this processor have one ?  We use it on a MPC860 processor (not
with GDB though) and I have used it with the efi332 boards (with GDB and their
home made BDM board).

I think you will find that there is a lot of code for GDB and 68k stubs.

Good luck,
Brendan Simon.



David Williams wrote:

> Hi All,
>
> I need some help to get started in modifying the appropriate parts of GDB
> so that I can remotely debug my system.
> I am using the Motorola MC68EZ328 (Dragonball EZ). It has a hardware
> breakpoint capability built in (not BDM as Dragonball is a 68000 core not
> CPU32). The hardware breakpoint capability would seem to be peculiar to
> this processor so I believe I will have to modify some parts(drivers etc)
> of GDB to use it. The processors breakpoint facility allows you to define a
> single address (and mask for ranges) to set a break-point on for either
> instruction or data accesses - read or write. This is great as can then set
> break-points in code without having to have code in RAM! A small problem is
> it only allows one hardware breakpoint to be set at a time.
>
> Another "small" problem is that I don't have a spare RS-232 port to
> communicate to GDB with. I have only one on my system. I have two options,
> as I see it. Firstly I could share the serial port between GDB and my
> application. One problem with this approach is will make debugging the IrDA
> part of my application more difficult. Secondly I could try and implement a
> software UART using the handshaking lines. Currently I think this second
> option may be better as long as a simple half duplex software UART can be
> implemented and provide adequate communications.
>
> Anyway what I would like to know is which parts of GDB to look at and what
> existing drivers/stubs etc I should use as templates for modification? Are
> DLDT drivers appropriate? Is GDB stub ("remote target") appropriate?
>
> Please point me in the right direction I am currently lost in a sea of
> documentation and source code with no maps!
>
> Note: I am currenty using ECGS 1.1.2 and have downloaded GDB 4.18
> distribution.


------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com