Dwayne Dietrich

BDM download speed with GDB/DDD

Discussion created by Dwayne Dietrich Employee on Mar 31, 2006
Latest reply on May 9, 2007 by jimmy henningsson
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

Outcomes