RE: [ECOS] Problems building stand-alone gdb stub for ARM AEB bo

[Gary Thomas <gthomas at redhat dot com>]

On 29-Sep-2000 Ormund Williams wrote:
> Hi
> 
> I have designed a board that uses the LH77790, the same chip that is on
> the ARM AEB.  I am now trying to build a gdb stub, first trying it on
> the AEB.  After going through the following steps:
> 
>     Create new target: awt60
>     Edit: hal_arm_awt60.cdl
>     Add CPU initialization code to: hal_platform_setup.h
>     Edit to match memory layout: mlt_arm_awt60_r*m.h/ldi
>     Build stub: ecosconfig new awt60 stubs
>                 ecosconfig tree
>                 make
>     Burn into PROM: gdb_module.bin
> 
> When I powerup the board, with minicom connected, I get:
> 
>     AWT60 eCos
>     +$T050f:e8140004;0d:601f0000;#50
> (the first time I saw that I popped a virtual bottle of champagne)
> 
> But an attempt to connect with gdb failed with the the error message:
> 
>     Remote debugging using /dev/ttyS0
>     Ignoring packet error, continuing...
>     Ignoring packet error, continuing...
>     Ignoring packet error, continuing...
>     Couldn't establish connection to remote target
>     Malformed response to offset query, timeout
> 
> I have been sending commands manually to the stub (very, very
> tedious!!).
> 
>     me:   $d#64  -- request stub version
>     stub: eCos GDB stubs - built Sep 29 2000 / 13:15:23#1c
> 
> so the stub is responding to this and other commands correctly, I can
> read and write memory, check and set registers but commands like "query
> offset" ($qOffsets#4b) just get an empty packet ($#00) in reply.
> 
> Does any body know where I should go from here, I'm stumped?
> 

What does your memory layout look like?  In particular, does it match
the AEB?  A common case of this sort of failure is trying to download
something which overwrites the GDB/stubs memory space, resulting in
mayhem.

Something you can try is to turn on remote debugging.  This will provide
some useful info about what packets get sent and what happens to them.
Just issue this command before trying the first command that talks with
the board.
  (gdb) set remotedebug 1