David Laban

GDB with the M5213EVB (dBUG OR BDM)

Discussion created by David Laban on Jul 14, 2006
Latest reply on Aug 23, 2006 by David Laban
I'm trying to use GDB with the M5213EVB. It has a dBUG monitor program on it, and a BDM interface. I have the P&E Microsystems USB coldfire Multilink BDM cable as well. The eventual aim is to have a redistributable tool chain for developing programs for our graphics overlay board which uses the 5213. Here are the things I've tried:
Using the PEmicro flasher and debugger: works fine, but only for small code, which isn't acceptable.
Using the SBCTools (www.steroidmicros.com) GDB binary (m68k-dbug-elf-gdb.exe) that came with an M5208EVB kit. The command:
(gdb) target dbug COM1
...and so on to load and run an elf binary...
works fine for the 5208, but not the 5213. See bottom of post for my thoughts as to why.
Using the SBCTools m68k-bdm-elf-gdb.exe binary doesn't even work on the 5208
(under cygwin, it is possible to address COM1 and COM2, but I haven't the first clue how to address a BDM interface on a USB port under cygwin, and there are no multilink drivers for linux (insert cynical comment about P&E here) )
Compiling the source provided on the SBCTools CD, using the configure options "--host=i686-pc-mingw32 --target=m68k-dbug-elf" This doesn't compile cleanly under cygwin. How did they get their binary out which worked? Are they distributing sources which aren't sufficient to create the appropriate binaries? If so, why?
==Debugging the behaviour of m68k-dbug-elf-gdb==
(don't bother reading below this line if you know the answer to any of my problems already. If you could just hit the reply button now and enlighten me, or if you're not registered, email to my gmail account (which I'm sure you can guess from my alias here) and I will post the answer here for all to see. That would be most pleasant of you.)
=Test case 1: the M5208EVB=
Putting a sniffer on COM1 shows that on the command:
target dbug COM1
gdb sends:
(where ^M is the return character)
over the serial port to the dBUG monitor, which resets itself and replies:

Software Reset
ColdFire MCF5208 on the M5208EVB
Firmware v4a.1a.10 (Built on Sep  1 2005 17:33:05)
Copyright 2005 Freescale Semiconductor, Inc.

Enter 'help' for help.
then GDB sends:
br -r^M
and gets
PC: 00000000 SR: 2000 [t.Sm.000...xnzvc]
An: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 40FE0000
Dn: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
then sends:
rd PC^M
and gets:
PC:  00000000
it then prints out to the terminal:
Remote target dbug connected to COM1
0x00000000 in ?? ()
and from there, you can load and run your executable how you want.
=Test case 2: the M5213EVB=
same command at the gdb console ( target dbug COM1 ) sends:
and gets:
Software Reset
ColdFire MCF5213 on the M5213EVB
Firmware v4a.1b.1b (Built on May 16 2005 15:45:20)
Copyright 2005 Freescale Semiconductor, Inc.
Enter 'help' for help.
it then gives up and gives the error:
remote-monitor: No such file or directory.
or if you're really lucky:
remote-monitor: No error.
and then refuses to let you load your elf binaries.
note: when the board and GDB are set to a high baud rate (115200) you also get an odd character sent on the serial link immediately after the reset command is sent. Switching both to 19200 removes this character, so I don't think this is causing my problems
=My questions=
Any kind of lead on either of these would be useful:
1) Why does GDB not interrogate dBUG further when it gets a response from the 5213? Does it examine the reply string for "5208" or something? If so, why? isn't dBUG supposed to be the same interface on all boards? Is it SBCTools trying to restrict the usefulness of its product?
2) How do you address the PEMicro BDM interface from within GDB?
3) How do you go about compiling GDB to get an executable that's the same as the one provided by SBCTools (from there, I'm sure I can modify it appropriately to work)?
Thanks in advance for *any* help you can offer.