[ECOS] Problems building stand-alone gdb stub for ARM AEB board

[ECOS] Problems building stand-alone gdb stub for ARM AEB board

[Ormund Williams]

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?

TIA

--
Ormund

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

[Gary Thomas]

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

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

[Ormund Williams]

Gary Thomas wrote:
> 
> 
> 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

Thanks Gary

The memory layout matches the board, gdb is failing to connect to the
stub so I cannot even attempt to download any thing to the board.  I
have narrowed the problem down to the serial communications.  It seems
that when I send a character at a time to the stub it responds correctly
but when I try gdb:
	
bash$ arm-elf-gdb 
GNU gdb 5.0
Copyright 2000 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "--host=i586-pc-linux-gnu --target=arm-elf".
(gdb) set debug remote 1
(gdb) set debug serial 1
(gdb) set remotebaud 38400 
(gdb) target remote /dev/ttyS0
Remote debugging using /dev/ttyS0
Sending packet: $Hc-1#09...[
r <Timeout: 2 seconds>]Sending packet: $Hc-1#09...[<Timeout: 2
seconds>]Sending packet: $Hc-1#09...[-]Nak
Sending packet: $Hc-1#09...[<Timeout: 2 seconds>][<Timeout: 2
seconds>]Timed out.
[<Timeout: 2 seconds>]Timed out.
[<Timeout: 2 seconds>]Timed out.
Ignoring packet error, continuing...
Sending packet: $qC#b4...[<Timeout: 2 seconds>]Sending packet:
$qC#b4...[<Timeout: 2 seconds>]Sending packet: $qC#b4...[<Timeout: 2
seconds>]Sending packet: $qC#b4...[<Timeout: 2 seconds>][<Timeout: 2
seconds>]Timed out.
[<Timeout: 2 seconds>]Timed out.
[<Timeout: 2 seconds>]Timed out.
Ignoring packet error, continuing...
Sending packet: $qOffsets#4b...[<Timeout: 2 seconds>]Sending packet:
$qOffsets#4b...[<Timeout: 2 seconds>]Sending packet:
$qOffsets#4b...[<Timeout: 2 seconds>]Sending packet:
$qOffsets#4b...[<Timeout: 2 seconds>][<Timeout: 2 seconds>]Timed out.
[<Timeout: 2 seconds>]Timed out.
[<Timeout: 2 seconds>]Timed out.
Ignoring packet error, continuing...
Couldn't establish connection to remote target
Malformed response to offset query, timeout
(gdb) 


I modified the following code in plf_stub.c to output the line status
register to the 4 LEDs:

// Read one character from the current serial port.
int hal_awt60_get_char(void)
{
  char c; //, leds;
  cyg_uint8 lsr;
  static cyg_uint8 i;

  do {
    HAL_READ_UINT8 (CYG_DEVICE_SERIAL_RS232_16550_LSR, lsr);
  } while ((lsr & SIO_LSR_DR) == 0);
  HAL_READ_UINT8 (CYG_DEVICE_SERIAL_RS232_16550_RBR, c);

  HAL_WRITE_UINT8 (PORT_C_LEDS, (lsr << 4));

  return c;
}

Framing errors are my problem.  Seems like a hardware problem, so I'll
work on that next.  Has any body seen this problem?

--
Ormund

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

[Gary Thomas]

On 04-Oct-2000 Ormund Williams wrote:
> Framing errors are my problem.  Seems like a hardware problem, so I'll
> work on that next.  Has any body seen this problem?
> 

Notice that when you connect, the host will be sending you a string of
6 characters or so at full speed.  If the target device does not have
buffering or isn't quick enough, then this will surely cause framing
errors when running at speed.

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

[Ormund Williams]

Gary Thomas wrote:
> 
> On 04-Oct-2000 Ormund Williams wrote:
> > Framing errors are my problem.  Seems like a hardware problem, so I'll
> > work on that next.  Has any body seen this problem?
> >
> 
> Notice that when you connect, the host will be sending you a string of
> 6 characters or so at full speed.  If the target device does not have
> buffering or isn't quick enough, then this will surely cause framing
> errors when running at speed.

The UART on the ARM AEB has no FIFO so each character must be read
before the next arrives, if that fails the Over-run flag is set in the
Line Status Register.  This I have tested by inserting a delay.

The problem I'm seeing though, is the Frame error flag is set.  This
only happens with some character sequences, from that I am concluding
that the board is malfunctioning, I am going to try a different one,
I'll let you know how it goes.


PS: There's no need to cc me since I'm subscribed to the list. Thanks

--
Ormund

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

[Ormund Williams]

Ormund Williams wrote:
> 
> Gary Thomas wrote:
> >
> > On 04-Oct-2000 Ormund Williams wrote:
> > > Framing errors are my problem.  Seems like a hardware problem, so I'll
> > > work on that next.  Has any body seen this problem?
> > >
> >
> > Notice that when you connect, the host will be sending you a string of
> > 6 characters or so at full speed.  If the target device does not have
> > buffering or isn't quick enough, then this will surely cause framing
> > errors when running at speed.
> 
> The UART on the ARM AEB has no FIFO so each character must be read
> before the next arrives, if that fails the Over-run flag is set in the
> Line Status Register.  This I have tested by inserting a delay.
> 
> The problem I'm seeing though, is the Frame error flag is set.  This
> only happens with some character sequences, from that I am concluding
> that the board is malfunctioning, I am going to try a different one,
> I'll let you know how it goes.
> 
> PS: There's no need to cc me since I'm subscribed to the list. Thanks
> 
> --
> Ormund

Hi

Found the problem!  My ARM AEB's serial port 1 is bad.  Using a MAX202,
some wire and 0.1u caps, I connected my PC to serial port 0 on the ARM
AEB and !!BANG!! gdb connected, no errors!  

Thanks

--
Ormund