BDM download speed with GDB/DDD

Dietrich — Sat, 01 Apr 2006 04:30:05 GMT

This message contains an entire topic ported from the WildRice - Coldfire forum. Freescale has received the approval from the WildRice administrator on seeding the Freescale forum with messages. The original message and all replies are in this single message. We have seeded this new forum with selected information that we expect will be of value as you search for answers to your questions. Freescale assumes no responsibility whatsoever with respect to Posted Material. For additional information, please see the Terms of Use - Message Boards and Community Forums. Thank You and Enjoy the Forum!

Mar 22, 2006, 5:53 PM

Post #1 of 6 (13 views)
Copy Shortcut
[ColdFire] BDM download speed with GDB/DDD Can't Post

--------------------------------------------------------------------------------

what type of download speeds are folks seeing with the cygwin or
linux ports using GDB (of DDD) with a parallel port (P&E Micro) BDM adapter ?

that how long does it take to download an image to the target. our
image size is currently around 1.5MB.

I would like to know if it significantly faster (or slower!) than the
(defunct) SDS debugger software we are using now.

Chris

--
Chris Russell
Chief Engineer, ZK Celltest Inc.
(408) 541-2621

Listserv
Veteran

Mar 23, 2006, 1:00 AM

Post #2 of 6 (13 views)
Copy Shortcut
Re: [ColdFire] BDM download speed with GDB/DDD [In reply to] Can't Post

--------------------------------------------------------------------------------

>
> what type of download speeds are folks seeing with the cygwin or
> linux ports using GDB (of DDD) with a parallel port (P&E Micro) BDM
adapter ?
>
> that how long does it take to download an image to the target. our
> image size is currently around 1.5MB.
>
> I would like to know if it significantly faster (or slower!) than the
> (defunct) SDS debugger software we are using now.
>
> Chris
>

I'd be surprised if there was a large difference in speed - the main
bottleneck is the parallel port and the bit-banging required by simple
adaptors. I think this is normally run at about 1 MHz, giving 500 kbits per
second on the BDM. Since you need 51 BDM clocks for every 32 bits data,
this works out to around 40 kBytes per second max download speed.

To get faster than that, you need to use a different interface - Ethernet or
USB. I have a prototype USB-based BDM adapator that I estimate gives 150 -
200 KB download speed, which I expect to get close to its theoretical
maximum of about 480 KB. At the moment, I've only got a rough Delphi
program for downloading - when I get the time, I plan to fill out gdb
support.

mvh.,

David

--------------------------------------------------------------------

Mar 23, 2006, 8:54 AM

Post #3 of 6 (11 views)
Copy Shortcut
Re: [ColdFire] BDM download speed with GDB/DDD [In reply to] Can't Post

--------------------------------------------------------------------------------

We used to download through GDB using a P&E BDM adapter and I
remember it being quite slow. Now we use Ed Sutter's MicroMonitor to
receive a "stripped" (of debug symbols) elf file over ethernet and
load the appropriate parts into memory. We then load GDB with the
debug info from a non-stripped version of the elf file and start
debugging. Others are doing similar things with other
bootloaders. Let me know if you need more details.

Steve

At 06:53 PM 3/22/2006, you wrote:

>what type of download speeds are folks seeing with the cygwin or
>linux ports using GDB (of DDD) with a parallel port (P&E Micro) BDM adapter ?
>
>that how long does it take to download an image to the target. our
>image size is currently around 1.5MB.
>
>I would like to know if it significantly faster (or slower!) than
>the (defunct) SDS debugger software we are using now.
>
>Chris
>
>
>--
>Chris Russell
>Chief Engineer, ZK Celltest Inc.
>(408) 541-2621

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

--------------------------------------------------------------------

Mar 23, 2006, 3:22 PM

Post #4 of 6 (10 views)
Copy Shortcut
Re: [ColdFire] BDM download speed with GDB/DDD [In reply to] Can't Post

--------------------------------------------------------------------------------

Steve Strobel wrote:
> We used to download through GDB using a P&E BDM adapter and I remember
> it being quite slow. Now we use Ed Sutter's MicroMonitor to receive a
> "stripped" (of debug symbols) elf file over ethernet and load the
> appropriate parts into memory. We then load GDB with the debug info
> from a non-stripped version of the elf file and start debugging. Others
> are doing similar things with other bootloaders. Let me know if you
> need more details.
>

What commands do you use to do this? I would like to try this.

--------------------------------------------------------------------
Mar 24, 2006, 2:10 PM

Post #5 of 6 (8 views)
Copy Shortcut
Re: [ColdFire] BDM download speed with GDB/DDD [In reply to] Can't Post

--------------------------------------------------------------------------------

At 04:22 PM 3/23/2006, Brian Rose wrote:
>Steve Strobel wrote:
>>We used to download through GDB using a P&E BDM adapter and I remember
>>it being quite slow. Now we use Ed Sutter's MicroMonitor to receive a "stripped"
>>(of debug symbols) elf file over ethernet and load the appropriate parts into
>>memory. We then load GDB with the debug info from a non-stripped version of
>>the elf file and start debugging. Others are doing similar things with other
>>bootloaders. Let me know if you need more details.
>
>What commands do you use to do this? I would like to try this.

My makefile creates three output files. The linker makes tcb2-debug.elf, which has
debug symbols and is about 34MB. It then calls "m68k-rtems-strip -o $@
$(RTEMS_TARGET)-debug.elf" to strip the debug symbols and create tcb2.elf
(about 1.7MB). Finally, it uses the elf.exe zlib compression program that comes
with MicroMonitor to create tcb2.ezip (about 650KB). For some targets, I skip the
last step and use an uncompressed elf file, because it lets the target start up
faster (it takes uMon a while to decompress *.ezip files).

I then transfer the tcb2.ezip file to the target using TFTP and let uMon save it in TFS
(its flash file system). For development work, it would be much nicer to use a TFS
ramdisk (because it would be faster and would prevent having to defragment the
flash file system every now and then), but I have never taken the time to set that up.
Even better would be a way to transfer an image directly to memory where it could
be executed. There is a way to do that with uMon if you use a binary image file, but
stuff in my elf file isn't stored contiguously, so making a binary image isn't
straightforward. By using an elf file in TFS, I can get uMon to parse the elf file and
automatically load the segments at the right addresses in memory. There might be
a way to get uMon to parse an elf file and load it into memory without first storing it
in TFS, but I haven't found one.

Once the file is in TFS, I can just execute it by entering "tcb2.ezip" from the uMon>
prompt I get via a serial connection to the target. It is also possible to use command
line options like "tcb2.ezip nocop" to disable the COP watchdog. I patched RTEMS
to make it pull the command line options from uMon, then just parsed the normal
argc/argv stuff to handle that.

The process I use from here on is more convoluted than it needs to be, because of
all the combinations I tried before I settled on the current method. I used to be able
to load the software through the BDM connection with GDB or using uMon/ethernet,
and either run GDB directly or DDD as a shell for GDB. It still deals with files for a
variety of different targets.

To run the program in a debugger, I use a script like tcb2-debug-ddd.sh:

#! /bin/bash
cd build/tcb2 ; ~/debug-tcb-ddd-net.sh tcb2 $1

which calls debug-tcb-ddd-net.sh:

#! /bin/bash
# must run this from a term window in X to start DDD

if [ $# -lt 1 ] # if have a command line argument
then
echo The name of the executable must be specified on the command line, like this:
echo $0 hello
exit 1
else
# this seems to be fooled into thinking that "loopback" is
# present if a zero byte "loopback.exe" is.
if [ -f "$1.ezip" ]
then
~/download.sh $1.ezip
~/moncmd.sh tfs -v ld $1.ezip
cp $1-debug.elf debug-net.elf
m68k-bdm-elf-gdb -silent --command=~/debug-tcb2-net.gdb
rm debug-net.elf
else
Echo File $1.ezip not found.
exit 2
fi
fi

Note that "~/moncmd.sh tfs -v ld $1.ezip" tells uMon to
decompress the file it has stored in TFS and load it into
memory (it understands elf files). That script is kind of
complicated because it is set up to work with several
types of target files.

The GDB command file (debug-tcb2-net.gdb) follows. Note
that it uses the "symbol" command to load the debug symbols.
It uses the reset vector to set the program counter, but
with an offset because of how we remap the flash during
the boot process (I am not sure we would still need to
now that we are using uMon, but that code has never been
simplified since it booted directly). It also sets up a
breakpoint to automatically stop and change a global
variable to disable the COP watchdog. Please let me know
if you have other questions.

tcb
symbol debug-net.elf
set $sp = *((long *) 0xf0000000)
# if used this, would start uMon over, after which could "call 0x20504" (or whatever the entry address is) to start the app
set $pc = (*((long *) 0xf0000004)) + 0xf0000000
# if use this, starts the application directly
set $pc = _start

b rtems_main
condition 1
commands 1
set do_mon_warmstart = 1
disable 1
end

# automatically disable the enable-cop command so it won't reset while debugging
b setup_cop_watchdog
condition 2
commands 2
set enable_cop_watchdog = 0
disable 2
c
end

b _uhoh
b __assert

# make sure the debugger will stop when the program exits
# hb pollethernet

---
Steve Strobel
Link Communications, Inc.
1035 Cerise Rd
Billings, MT 59101-7378
(406) 245-5002 ext 102
(406) 245-4889 (fax)

--------------------------------------------------------------------
Mar 24, 2006, 3:08 PM

Post #6 of 6 (8 views)
Copy Shortcut
Re: [ColdFire] BDM download speed with GDB/DDD [In reply to] Can't Post

--------------------------------------------------------------------------------

Steve Strobel wrote:
> Even better would be a way to transfer an image directly to memory where it could
> be executed. There is a way to do that with uMon if you use a binary image file, but
> stuff in my elf file isn't stored contiguously, so making a binary image isn't
> straightforward.

Would a simpler method be to add at the entry point of your application:

_start:
halt
nop
...

Then in your .gdbinit file add:

define hook-stop
if $pc == _start
si
end
end

target bdm /dev/bdmcf0

c
tb main
c

Set up your boot monitor to load the application into RAM and start
executing it.

On the command line you start ddd (gdb) with the ELF file with symbols
on the command line.

Regards
Chris

Message Edited by Dietrich on 04-04-2006 09:18 PM

Re: BDM download speed with GDB/DDD

jkbpower — Wed, 09 May 2007 13:22:00 GMT

David said: At the moment, I've only got a rough Delphi
program for downloading - when I get the time, I plan to fill out gdb
support.

Have you written delphi software to download with PE:s cable 32 interface ?

Is it possible to download to a 68k332 processor system?

mvh

Jimmy

topic BDM download speed with GDB/DDD in ColdFire/68K Microcontrollers and Processors

BDM download speed with GDB/DDD

Re: BDM download speed with GDB/DDD