[uClinux-dev] BDM revisited
tandrews at mindspring.co.za
Thu Nov 29 03:01:21 EST 2001
Bruce Paterson wrote:
> I can examine memory using "x /100 100" in the console window, but
> occasionally it comes
> back with "BDM error: Invalid target command". It really does seem to be
> talking to the target
v. Interesting. I'm having the same problem, but I can load and single-step
no problem. It took me ages to get the correct .gdbinit68 file though! (see end)
I'm using a genuine P&E BDM - I've been hacking bdm.c and I've found that
the driver often thinks the processor is not stopped even though it is. I
think this comes down to reading the freeze line. I'm about to put a logic
analyzer on it. What BDM are you using ? I was sort of thinking that other
people make their own BDM's and that perhaps there's a timing difference
somewhere. It's ages since I programmed a GAL, but I might end up doing that
just to see if the open-source version of the ICD BDM works better. The
circuit diagram certainly is almost identical (minus a couple of LED's)
Have you tried testing your BDM with cpu32_check ? It's in
gdb-bdm-20010901/test. This is the proggie I used to identify the source of
the BDM problems: bdm.c
> I can't load files though !!
> If I try "load afile" in the console window it always comes back with
> "Error: Not an object file".
> I get this error for binary, elf and coff format files. I have tried
> both explicit paths or
> "cd xxx". "Download" menu option fails with the same error. It's a bit
> of a mystery whats going
> on here ! In the old m68k-coff-gdb "load" used to load a binary image
> no problem.
I do remember getting this error, but I'm not sure how I fixed it - sorry.
Have a look at my init file - maybe all the "directory" statements solved
it. I seem to recall the error message being a little misleading.
I built the patched version of 2.0.38 as if I were using the lineo uCQuicc.
The only files I modified were platform/68360/uCquicc/ram.ld (I have less
RAM) and platform/68360/uCquicc/crt0_ram.S to make PEPAR match my DRAM.
When I built the linux kernel, I didn't do a "make linux.bin" - for no
reason I just did a "make", and I just "load linux".
I have found one thing about Insight to be *really* misleading. If you
display ram, you see what "ought" to be there, even if the chip is not yet
set up. My rule of thumb is if the registers are displayed (with data) then
it's probably ok. The only real test is to write a byte to the ram.
The other thing about Insight is that I can't figure out when it refreshes
it's take on the registers. Often I close that window and re-open it to make
I think these Insight problems stem from it being written to debug x86 code
running locally, so some assumptions are made. Using "set remotecache off"
is only a partial solution.
My .gdbinit68 file:
#target bdm /dev/icd_bdm0
target bdm /dev/bdmidc0
set remotecache off
# bdm_log on
# bdm_debug_driver 1
# bdm_timetocomeup 600000
# bdm_autoreset off
#set *(long *)0xfffff000=0x0001428f
set *(long *)0xfffff000=0x000005cff
set *(char *)0xfffff022=0x03F
#set *(long *)0xfffff040=0x18d026a0
set *(long *)0xfffff040=0x17b00020
#set *(long *)0xfffff050=0x00000001
set *(long *)0xfffff050=0x70000001
set *(long *)0xfffff054=0x20000004
#set *(long *)0xfffff060=0x10000001
set *(long *)0xfffff060=0x00000001
set *(long *)0xfffff064=0x0fc00001
#set *(long *)0xfffff070=0x10400001
set *(long *)0xfffff070=0x00400001
set *(long *)0xfffff074=0x0fc00001
set *(long *)0xfffff080=0x20000001
set *(long *)0xfffff084=0x30000004
set *(long *)0xfffff090=0x30000001
set *(long *)0xfffff094=0x30000004
set *(long *)0xfffff0a0=0x40000001
set *(long *)0xfffff0a4=0x60000002
set *(long *)0xfffff0b0=0x50000001
set *(long *)0xfffff0b4=0x40000004
set *(long *)0xfffff0c0=0x60000001
set *(long *)0xfffff0c4=0x30000004
set *(char *)0xfffff00c=0x8c
# why doesn't it like this one ???
# set *(short *)0xfffff010=0xb274
# set *(short *)0xfffff010=0xb274
#set *(short *)0xfffff014=0x0000
set *(short *)0xfffff014=0x0780
#set *(short *)0xfffff016=0x0080
set *(short *)0xfffff016=0x0780
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/
More information about the uClinux-dev