GDB with the M5213EVB (dBUG OR BDM)

[alsuren]

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:

reset^M

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

dBUG>

then GDB sends:

br -r^M

rd^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

dBUG>

it then prints out to the terminal:

Remote target dbug connected to COM1

0x00000000 in ?? ()

(gdb)

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:

reset^M

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.

dBUG>

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.

[mvincent]

I can't answer your questions as I am not familiar with SBC tools. However, I suggest you give CodeSourcery's G++ For Coldfire a try. Its up-to-date, actively supported. They redirect the standard GDB remote protocol stream to their own m68k-cfpe-stub program which acts as a GDB stub, but runs (typically) on the same system as GDB and converts the GCC commands into calls to the UNITCFZ dll to drive any of P&E's BDM interface (parallel, USB, CycloneMax). You can try it free; their subscriptions model is quite affordable and includes an Eclipse-based IDE.

[alsuren]

That sounds like a novel way of doing things. Might have to try that. Obviously, the ideal solution is to get something that's redistributable, with standard tools, so possibly making a stub which runs over rs232, or using the standard dBUG interface might be the answer. Can anyone recommend a public domain BDM device that works with USB, rs232 or ethernet?

In the mean time, I've been playing with GDB/dBUG over rs232, and I've managed to get the vanilla gdb-6.5 to compile under cygwin. Initially I got an "inapropriate ioctl for device, but it turned out that cygwin requires you to specify "target dbug /dev/com1", even though the devices in /dev aren't visible if you use ls (the original binary was 6.0, and probably compiled under mingw or something, so wants you to specify "target dbug COM1".)

The next problem is that the sample project templates supplied by P&E don't work as advertised, so you can't change the memory map simply by editing a few linker variables. My next task is to write something from scratch that will run under the supervision of dBUG.

I'll post back here when I get something *truly* working.

[alsuren]

Correction: The P&E sample projects *do* work as advertised, and you *can* put them into RAM, simply by changing the memory map, but dBUG handles interrupts, and doesn't let you take control of them, so if you want to run under dBUG, you still need to change code. See http://forums.freescale.com/freescale/board/message?board.id=CWCOMM&message.id=1319 for details, when I work out how to get it working.

Hopefully, as part of my project, I will create an installable zip file which includes msys, gdb, eclipse and a gcc compiler (with appropriate sources, and compilation instructions, so you can compile the same thing again with no problems). Time is running out though, because I only have 1 and a half weeks left, and my company hasn't finished soldering up their development board yet, and I'm on the *verge* of getting interrupts working. Also, at some point, I need to get the dBUG monitor compiled with my custom GCC, and uploaded to the original development board with cfflasher (or the dldbug command, if I'm feeling particularly adventurous). There is also a nice little project for an open source USB BDM interface, which could be an interesting twist in this particular tale. See http://forums.freescale.com/freescale/board/message?board.id=CFCOMM&message.id=624&jump=true for details.

Is it just me, or do open source projects have a habit of looking like they'll be abso-frick'n-lutely amazing... in about a week's time?

[alsuren]

Correction: dBUG does copy the vector table into RAM, so it *is* possible to overwrite the vectors by hand, using C that looks like:

*(long*)(0x20000098) = (long*)&trap6;

where trap6 is defined as something like:

 void __attribute__ ((interrupt)) trap6 (){board_putchar('6');}

and triggered using asm( "trap #6" );

Note that this is using GNU C Compiler, and I don't know what the equiv. codewarrior syntax is. I also don't know how to count, so that hex pointer might be completely wrong. Try using trap #3..7 if it doesn't initially work.