Can't connect to remote Evaluator 7T

Can't connect to remote Evaluator 7T

[Pierre Habraken]

Hello,

I am trying to set up a practical work session about interruption
handling for undergradate students.
We are using for this work Arm Evaluator 7T boards connected to Intel
Linux boxes via a serial link.
The tools for writing programs and observing their execution are
arm-elf-gcc, arm-elf-as, arm-elf-gdb and other Gnu tools.

I did some first trials using the Angel monitor which comes installed on
each board. I used for this the target rdi provided with gdb.

Now I want to use RedBoot instead of Angel.
I uploaded redboot.UU onto the board and then verified (using a
communication program) that redboot was properly installed (see redboot
banner below).
But when I launch arm-elf-gdb and type the command 'target remote
/dev/ttyS0' then gdb fails to talk to redboot :
=================================================================
$ arm-elf-gdb
GNU gdb 5.2
...
This GDB was configured as "--host=i686-pc-linux-gnu --target=arm-elf".
(gdb) set remotebaud 38400
(gdb) target remote /dev/ttyS0
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
=================================================================
Could it be that the serial line is not configured as required on the
gdb side ? (using ckermit I had to force parity to none...)

Thanks a lot in advance for any help.

Pierre

=================================================================
ARM Evaluator7T Boot Strap Loader Release 1.01
Press ENTER within 2 seconds to stop autoboot
+
RedBoot(tm) bootstrap and debug environment - built 11:00:52, Jul  2
2001

Copyright (C) 2000, 2001, Red Hat, Inc.

RAM: 0x00000000-0x00080000, 0x0000c470-0x00080000 available
RedBoot> 
=================================================================
-- 
________________________________________________________________________
Pierre HABRAKEN - mailto:Pierre.Habraken@imag.fr
Tél: 04 76 82 72 83 - Fax: 04 76 82 72 87
IMAG-LSR BP72 38402 SAINT MARTIN D'HERES Cedex
________________________________________________________________________

Re: [ECOS] Can't connect to remote Evaluator 7T

[Jonathan Larmour]

Pierre Habraken wrote:
> 
> Now I want to use RedBoot instead of Angel.
> I uploaded redboot.UU onto the board and then verified (using a
> communication program) that redboot was properly installed (see redboot
> banner below).
> But when I launch arm-elf-gdb and type the command 'target remote
> /dev/ttyS0' then gdb fails to talk to redboot :
> =================================================================
> $ arm-elf-gdb
> GNU gdb 5.2
> ...
> This GDB was configured as "--host=i686-pc-linux-gnu --target=arm-elf".
> (gdb) set remotebaud 38400
> (gdb) target remote /dev/ttyS0
> 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
> =================================================================
> Could it be that the serial line is not configured as required on the
> gdb side ? (using ckermit I had to force parity to none...)

Possible, but unlikely since you're receiving stuff at all (packet errors, 
not just timeout) and I assume you have the baud rate right :-).

Before target remote you could do:

set debug remote 1

to see what that says. If that doesn't reveal anything interesting then 
(if I'm remembering right) you can also do:

set remotelogfile gdblog.txt

before the target remote, which should give a slightly more accurate 
version of what was sent/received, into the file gdblog.txt.

Jifl
-- 
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
--[ "You can complain because roses have thorns, or you ]--
--[  can rejoice because thorns have roses." -Lincoln   ]-- Opinions==mine

Re: [ECOS] Can't connect to remote Evaluator 7T

[Pierre Habraken]

Here is the contents of gdblog.txt :
w +$Hc-1#09
r <Timeout: 2 seconds>
w $Hc-1#09
r <Timeout: 2 seconds>
w $Hc-1#09
r <Timeout: 2 seconds>
w $Hc-1#09
r <Timeout: 2 seconds><Timeout: 2 seconds>
w -
r <Timeout: 2 seconds>
w -
r <Timeout: 2 seconds>
w -+$qC#b4
r <Timeout: 2 seconds>
w $qC#b4
r <Timeout: 2 seconds>
w $qC#b4
r <Timeout: 2 seconds>
w $qC#b4
r <Timeout: 2 seconds><Timeout: 2 seconds>
w -
r <Timeout: 2 seconds>
w -
r <Timeout: 2 seconds>
w -+$qOffsets#4b
r <Timeout: 2 seconds>
w $qOffsets#4b
r <Timeout: 2 seconds>
w $qOffsets#4b
r <Timeout: 2 seconds>
w $qOffsets#4b
r <Timeout: 2 seconds><Timeout: 2 seconds>
w -
r <Timeout: 2 seconds>
w -
r <Timeout: 2 seconds>
w -+
End of log

What is strange is that if I quit gdb and then launch kermit at once
without resetting the board, then redboot is there responding to
commands such as 'version'. It looks like if redboot is prepared to
execute basic commands but not to talk to gdb...
About the serial settings, I did not find any gdb command allowing to
change anything but the baudrate. I know that the speed is correct
(38400) but have no idea concerning the others parameters (parity,
etc.).

Pierre


Jonathan Larmour wrote:
> 
> Pierre Habraken wrote:
> >
> > Now I want to use RedBoot instead of Angel.
> > I uploaded redboot.UU onto the board and then verified (using a
> > communication program) that redboot was properly installed (see redboot
> > banner below).
> > But when I launch arm-elf-gdb and type the command 'target remote
> > /dev/ttyS0' then gdb fails to talk to redboot :
> > =================================================================
> > $ arm-elf-gdb
> > GNU gdb 5.2
> > ...
> > This GDB was configured as "--host=i686-pc-linux-gnu --target=arm-elf".
> > (gdb) set remotebaud 38400
> > (gdb) target remote /dev/ttyS0
> > 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
> > =================================================================
> > Could it be that the serial line is not configured as required on the
> > gdb side ? (using ckermit I had to force parity to none...)
> 
> Possible, but unlikely since you're receiving stuff at all (packet errors,
> not just timeout) and I assume you have the baud rate right :-).
> 
> Before target remote you could do:
> 
> set debug remote 1
> 
> to see what that says. If that doesn't reveal anything interesting then
> (if I'm remembering right) you can also do:
> 
> set remotelogfile gdblog.txt
> 
> before the target remote, which should give a slightly more accurate
> version of what was sent/received, into the file gdblog.txt.
> 
> Jifl
> --
> eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
> --[ "You can complain because roses have thorns, or you ]--
> --[  can rejoice because thorns have roses." -Lincoln   ]-- Opinions==mine

-- 
________________________________________________________________________
Pierre HABRAKEN - mailto:Pierre.Habraken@imag.fr
Tél: 04 76 82 72 83 - Fax: 04 76 82 72 87
IMAG-LSR BP72 38402 SAINT MARTIN D'HERES Cedex
________________________________________________________________________

Re: [ECOS] Can't connect to remote Evaluator 7T

[Jonathan Larmour]

Pierre Habraken wrote:
> Here is the contents of gdblog.txt :
> w +$Hc-1#09
> r <Timeout: 2 seconds>
[snip]

Oh, my mistake, you really are reading absolutely nothing from the target, 
rather than it being corruption.

> What is strange is that if I quit gdb and then launch kermit at once
> without resetting the board, then redboot is there responding to
> commands such as 'version'.

If it is, then it can't have received anything from GDB that told it to 
switch to GDB remote protocol mode. Otherwise you wouldn't be able to as 
it would be expecting GDB output.

> About the serial settings, I did not find any gdb command allowing to
> change anything but the baudrate. I know that the speed is correct
> (38400) but have no idea concerning the others parameters (parity,
> etc.).

Unfortunately GDB can't. I suggest you look at flow control and ensure 
that is off. Also make sure nothing else is accessing the serial port at 
the time. Try minicom instead of ckermit just in case.

Jifl
-- 
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
--[ "You can complain because roses have thorns, or you ]--
--[  can rejoice because thorns have roses." -Lincoln   ]-- Opinions==mine

Re: [ECOS] Can't connect to remote Evaluator 7T

[Mark Salter]

>>>>> Jonathan Larmour writes:

> Pierre Habraken wrote:
>> Here is the contents of gdblog.txt :
>> w +$Hc-1#09
>> r <Timeout: 2 seconds>
> [snip]

> Oh, my mistake, you really are reading absolutely nothing from the target, 
> rather than it being corruption.

Not only that, from my experiments with a cable tap, nothing is going out
of the PC to the target. The write(2) succeeds, but nothing is sent on
the wire. Closing and reopening the serial device usually clears up the
problem.

>> What is strange is that if I quit gdb and then launch kermit at once
>> without resetting the board, then redboot is there responding to
>> commands such as 'version'.

> If it is, then it can't have received anything from GDB that told it to 
> switch to GDB remote protocol mode. Otherwise you wouldn't be able to as 
> it would be expecting GDB output.

Exactly.

--Mark

Re: [ECOS] Can't connect to remote Evaluator 7T

[Quality Quorum]

On Wed, 19 Feb 2003, Mark Salter wrote:

>
> Not only that, from my experiments with a cable tap, nothing is going out
> of the PC to the target. The write(2) succeeds, but nothing is sent on
> the wire. Closing and reopening the serial device usually clears up the
> problem.

Connect through minicom and make sure that target responds with gdb packet
when you send enter. My $0.02.

>
>
> --Mark
>
>

Thanks,

Aleksey

Re: [ECOS] Can't connect to remote Evaluator 7T

[Mark Salter]

>>>>> Quality Quorum writes:

> On Wed, 19 Feb 2003, Mark Salter wrote:

>> 
>> Not only that, from my experiments with a cable tap, nothing is going out
>> of the PC to the target. The write(2) succeeds, but nothing is sent on
>> the wire. Closing and reopening the serial device usually clears up the
>> problem.

> Connect through minicom and make sure that target responds with gdb packet
> when you send enter. My $0.02.

The target is sitting at the RedBoot prompt. I physically tapped the
serial line and watched from another host. The packet from GDB never
makes it to the wire. If I startup minicom on the host with GDB still
trying to connect, then data starts flowing on the wire again although
GDB and minicom are fighting over the read data.

--Mark

Re: [ECOS] Can't connect to remote Evaluator 7T

[Gary D. Thomas]

On Wed, 2003-02-19 at 10:41, Mark Salter wrote:
> >>>>> Quality Quorum writes:
> 
> > On Wed, 19 Feb 2003, Mark Salter wrote:
> 
> >> 
> >> Not only that, from my experiments with a cable tap, nothing is going out
> >> of the PC to the target. The write(2) succeeds, but nothing is sent on
> >> the wire. Closing and reopening the serial device usually clears up the
> >> problem.
> 
> > Connect through minicom and make sure that target responds with gdb packet
> > when you send enter. My $0.02.
> 
> The target is sitting at the RedBoot prompt. I physically tapped the
> serial line and watched from another host. The packet from GDB never
> makes it to the wire. If I startup minicom on the host with GDB still
> trying to connect, then data starts flowing on the wire again although
> GDB and minicom are fighting over the read data.
> 

Maybe it's a handshake issue?  Perhaps GDB is leaving or setting
the port into a handshake mode (that may not work) and minicom does
not.  Or some such combination.  Checking with "stty </dev/XXX"
from another window while both applications are running might
give some useful insights.

-- 
.--------------------------------------------------------.
|       Mind: Embedded Linux and eCos Development        |
|--------------------------------------------------------|
| Gary Thomas              email:  gary.thomas@mind.be   |
| Mind ( http://mind.be )  tel:    +1 (970) 229-1963     |
| gpg: http://www.chez-thomas.org/gary/gpg_key.asc       |
'--------------------------------------------------------'

Re: [ECOS] Can't connect to remote Evaluator 7T

[Jonathan Larmour]

Gary D. Thomas wrote:
> On Wed, 2003-02-19 at 10:41, Mark Salter wrote:
> 
>>>>>>>Quality Quorum writes:
>>
>>>On Wed, 19 Feb 2003, Mark Salter wrote:
>>
>>>>Not only that, from my experiments with a cable tap, nothing is going out
>>>>of the PC to the target. The write(2) succeeds, but nothing is sent on
>>>>the wire. Closing and reopening the serial device usually clears up the
>>>>problem.
>>
>>>Connect through minicom and make sure that target responds with gdb packet
>>>when you send enter. My $0.02.
>>
>>The target is sitting at the RedBoot prompt. I physically tapped the
>>serial line and watched from another host. The packet from GDB never
>>makes it to the wire. If I startup minicom on the host with GDB still
>>trying to connect, then data starts flowing on the wire again although
>>GDB and minicom are fighting over the read data.
>>
> 
> 
> Maybe it's a handshake issue?  Perhaps GDB is leaving or setting
> the port into a handshake mode (that may not work) and minicom does
> not.  Or some such combination.  Checking with "stty </dev/XXX"
> from another window while both applications are running might
> give some useful insights.

As I said earlier :-). I think making sure it's off using minicom would be 
more reliable (from user error) though.

Here's how to do it in minicom:
CTRL-A Z O
select Serial port setup
Make sure both hardware and software flow control are off, and the other 
serial settings are right (38400 8-N-1).

Press return
Choose Exit
Ctrl-A Z q
select yes

You could also force Redboot into GDB mode by typing a $. You should lose 
the prompt then. Typing something like:
+$k#6b
should make it react and then return to the command prompt.

Jifl
-- 
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
--[ "You can complain because roses have thorns, or you ]--
--[  can rejoice because thorns have roses." -Lincoln   ]-- Opinions==mine

Re: [ECOS] Can't connect to remote Evaluator 7T

[Mark Salter]

>>>>> Jonathan Larmour writes:

> Gary D. Thomas wrote:
>> On Wed, 2003-02-19 at 10:41, Mark Salter wrote:
>> 
>>>>>>>> Quality Quorum writes:
>>> 
>>>> On Wed, 19 Feb 2003, Mark Salter wrote:
>>> 
>>>>> Not only that, from my experiments with a cable tap, nothing is going out
>>>>> of the PC to the target. The write(2) succeeds, but nothing is sent on
>>>>> the wire. Closing and reopening the serial device usually clears up the
>>>>> problem.
>>> 
>>>> Connect through minicom and make sure that target responds with gdb packet
>>>> when you send enter. My $0.02.
>>> 
>>> The target is sitting at the RedBoot prompt. I physically tapped the
>>> serial line and watched from another host. The packet from GDB never
>>> makes it to the wire. If I startup minicom on the host with GDB still
>>> trying to connect, then data starts flowing on the wire again although
>>> GDB and minicom are fighting over the read data.
>>> 
>> 
>> 
>> Maybe it's a handshake issue?  Perhaps GDB is leaving or setting
>> the port into a handshake mode (that may not work) and minicom does
>> not.  Or some such combination.  Checking with "stty </dev/XXX"
>> from another window while both applications are running might
>> give some useful insights.

> As I said earlier :-). I think making sure it's off using minicom would be 
> more reliable (from user error) though.

% stty -a </dev/ttyS0
speed 115200 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W;
lnext = ^V; flush = ^O; min = 1; time = 5;
-parenb -parodd cs8 hupcl -cstopb cread clocal -crtscts
ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff
-iuclc -ixany -imaxbel
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0
ff0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop
-echoprt -echoctl -echoke

Starting minicom does not reliably get it going again. If I wait for GDB
to timeout and retry a target command, it usually works. The act of closing/
opening the tty device seems to get it unclogged.

--Mark

Re: [ECOS] Can't connect to remote Evaluator 7T

[Pierre Habraken]

Mark Salter wrote:
> [...]
> % stty -a </dev/ttyS0
> speed 115200 baud; rows 0; columns 0; line = 0;
> intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
> eol2 = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
> werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 5;
> -parenb -parodd cs8 hupcl -cstopb cread clocal -crtscts
                                                 ^^^^^^^^
Ok, I got it : hardware control flow was enabled (crtscts instead of
-crtscts).
So, now the command 'target remote' sets up the connection, but
uploading (command 'load') the program to the board fails, leaving gdb
accepting no more keyboard input (not even ^C, I have to kill it from an
other xterm).

I attach below the gdb trace with logging disabled and also the contents
of the file gdblog.txt produced when logging is enabled (beginning of
the file only) :

Anyone an idea ?

Pierre

===============================================================
$ arm-elf-gdb
GNU gdb 5.2
...
This GDB was configured as "--host=i686-pc-linux-gnu --target=arm-elf".
(gdb) set remotebaud 38400
(gdb) file guirlande
Reading symbols from guirlande...done.
(gdb) target remote /dev/ttyS0
Remote debugging using /dev/ttyS0
0x018210a8 in ?? ()
(gdb) load
Loading section .text, size 0x3bec lma 0x8000
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Killed
$
===============================================================
w +$Hc-1#09
r +$OK#9a
w +$qC#b4
r +$E02#a7
w +$qOffsets#4b
r +$#00
w +$?#3f
r +$S05#b8
w +$Hg0#df
r +$OK#9a
w +$g#67
r
+$0100000001000000bcbb000050000000020000005000000000000000500000001cbc0000fdffffff58c40000f0b30000f4b30000e4b30000e4498201a810820100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000d3000020#7e
w +$mb3f0,4#f8
r +$a8108201#c5
w +
c load
w $X8000,0:#b6
r +$OK#9a
w
+$X8000,135:\x16\x00\xa0\xe3\xc4\x10\x8f\xe2V4\x12\xef\xbc\x00\x9f\xe5\b\xd0\x90\xe5\f\xa0\x90\xe5\x01\xac\x8a\xe2\x00\x10\xa0\xe3\x01\xb0\xa0\xe1\x01p\xa0\xe1\xa4\x00\x9f\xe5\xa4
\x9f\xe5\x00
B\xe0\xe3\t\x00\xeb\x85\n\x00\xeb\x15\x00\xa0\xe3\x94\x10\x8f\xe2V4\x12\xef\x8c\x10\x9f\xe5\x00\x00\xa0\xe3\x010\xd1\xe4\x00\x00S\xe3\x11\x00\x00\n
\x00S\xe3\xfa\xff\xff\n"\x00S\xe3'\x00S\x13\x03 \xa0\x01

\xa0\x13\x01\x10A\x12\x02\x00-\xe9\x01\x00\x80\xe2\x010\xd1\xe4\x00\x00S\xe3\x05\x00\x00\n\x03\x00R\xe1\xfa\xff\xff\x1a\x00
\xa0\xe3\x010A\xe2\x00
\xc3\xe5\xea\xff\xff\xea\r\x10\xa0\xe1\x00!\x8d\xe0\r0\xa0\xe1\x03\x00R\xe1\x04@\x12\x85\x00P\x93\x85\x04P"\x85\x04@\x83\x84\xf9\xff\xff\x8a4\x01\x00\xeb\xdb\x07\x00\xeb\xe4\xbd\x00\x00d\xc6\x00\x00D\xc7\x00\x00\xf4\xbd\x00\x00\xff\x00\x00\x00\r\xc0\xa0\xe1\x00\xd8-\xe9\x04\xb0L\xe2\f\xd0M\xe2\x1c0\xa0\xe3\x100\v\xe5\xe8
\x9f\xe5\x100\x1b\xe5\x020c\xe0\x140\v\xe5\x140\x1b\xe5\b0C\xe2}\x031\xa0\xe1\x140\v\xe5\x140\x1b\xe5\xff4\x03\xe2\x00\x00S\xe3.\x00\x00\x1a\x100\x1b\xe5\x000\x93\xe5\xff#f4
r +$OK#9a
w +$X8135,135:.\xc3\xe3\x0f
\xc2\xe3\xe54\xa0\xe3\x9f8\x83\xe2\x0f:\x83\xe2\x03\x00R\xe1\x0e\x00\x00\x1a\x100\x1b\xe5\x00
\x93\xe5\xe54\xa0\xe3\x9f8\x83\xe2\x0f:\x83\xe2\x030"\xe0\x180\v\xe5\x180\x1b\xe5\x03!\xa0\xe1\x100\x1b\xe5\x030\x82\xe0 
\x83\xe2h0\x9f\xe5\x00
\x83\xe5\x10\x00\x00\xea\x100\x1b\xe5\x000\x93\xe5\xff4\x03\xe2\xea\x04S\xe3\v\x00\x00\x1a\x100\x1b\xe5\x000\x93\xe5\xea4}\x03\xe2\x031\xa0\xe1\x180\v\xe5\x180\x1b\xe5\x03!\xa0\xe1\x100\x1b\xe5\x030\x82\xe0 
\x83\xe2 0\x9f\xe5\x00 \x83\xe5\x140\x1b\xe5\xea4\x83\xe3\x140\v\xe5\x14
\x1b\xe5\x100\x1b\xe5\x00
\x83\xe5\x00\xa8\x1b\xe9\x10\xbc\x00\x00\xf4\xbe\x00\x00\r\xc0\xa0\xe1\x00\xd8-\xe9\x04\xb0L\xe2\xff'\xa0\xe36*\x82\xe2\xff7\xa0\xe36:\x83\xe2\x000\x93\xe5\x010\xc3\xe3\x000\x82\xe5\xff'\xa0\xe36*\x82\xe2\xff7\xa0\xe36:\x83\xe2\x000\x93\xe5\x020\xc3\xe3\x000\x82\xe5\xff\x17\xa0\xe36\x1a\x81\xe2\x04\x10\x81\xe2\x000\xa0\xe1\x031\xa0\xe1\x000\x83\xe0\x03!\xa0\xe1\x020\x83\xe0\x830\xa0\xe1\x010C\xe2\x000\x81\xe5\x00\xa8\x1b\xe9\r\xc0#d7
r +<Timeout: 2 seconds>
w -
r <Timeout: 2 seconds>
w -
r <Timeout: 2 seconds>
w
-+$X826a,136:\xa0\xe1\x00\xd8-\xe9\x04\xb0L\xe2\xff'\xa0\xe36*\x82\xe2\xff7\xa0\xe36:\x83\xe2\x000\x93\xe5\b0\xc3\xe3\x000\x82\xe5\xff'\xa0\xe36*\x82\xe2\xff7\xa0\xe36:\x83\xe2\x000\x93\xe5\x100\xc3\xe3\x000\x82\xe5\xff\x17\xa0\xe36\x1a\x81\xe2\b\x10\x81\xe2\x000\xa0\xe1\x031\xa0\xe1\x000\x83\xe0\x03!\xa0\xe1\x020\x83\xe0\x830\xa0\xe1\x010C\xe2\x000\x81\xe5\x00\xa8\x1b\xe9\r\xc0\xa0\xe1\x00\xd8-\xe9\x04\xb0L\xe2\xff'\xa0\xe35*\x82\xe2\x04
\x82\xe2\xff7\xa0\xe35:\x83\xe2\x040\x83\xe2\x000\x93\xe5i4\xc3\xe3\xbf8\xc3\xe3?;\xc3\xe3\x000\x82\xe5\xff'\xa0\xe35*\x82\xe2\x04
\x82\xe2\xff7\xa0\xe35:\x83\xe2\x040\x83\xe2\x000\x93\xe5\x1f0\xc3\xe3\x000\x82\xe5\xff'\xa0\xe35*\x82\xe2\x04
\x82\xe2\xff7\xa0\xe35:\x83\xe2\x040\x83\xe2\x000\x93\xe5\x190\x83\xe3\x000\x82\xe5\xff'\xa0\xe35*\x82\xe2\xff7\xa0\xe35:\x83\xe2\x000\x93\xe5\xf00\x83\xe3\x000\x82\xe5\xff'\xa0\xe35*\x82\xe2\xff7\xa0\xe35:\x83\xe2\x000\x93\xe5\x7f;\x83\xe3\x000\x82\xe5\xff'\xa0\xe35*\x82\xe2\xff7\xa0\xe3#b0
r <Timeout: 2 seconds>
w
$X826a,136:\xa0\xe1\x00\xd8-\xe9\x04\xb0L\xe2\xff'\xa0\xe36*\x82\xe2\xff7\xa0\xe36:\x83\xe2\x000\x93\xe5\b0\xc3\xe3\x000\x82\xe5\xff'\xa0\xe36*\x82\xe2\xff7\xa0\xe36:\x83\xe2\x000\x93\xe5\x100\xc3\xe3\x000\x82\xe5\xff\x17\xa0\xe36\x1a\x81\xe2\b\x10\x81\xe2\x000\xa0\xe1\x031\xa0\xe1\x000\x83\xe0\x03!\xa0\xe1\x020\x83\xe0\x830\xa0\xe1\x010C\xe2\x000\x81\xe5\x00\xa8\x1b\xe9\r\xc0\xa0\xe1\x00\xd8-\xe9\x04\xb0L\xe2\xff'\xa0\xe35*\x82\xe2\x04
\x82\xe2\xff7\xa0\xe35:\x83\xe2\x040\x83\xe2\x000\x93\xe5i4\xc3\xe3\xbf8\xc3\xe3?;\xc3\xe3\x000\x82\xe5\xff'\xa0\xe35*\x82\xe2\x04
\x82\xe2\xff7\xa0\xe35:\x83\xe2\x040\x83\xe2\x000\x93\xe5\x1f0\xc3\xe3\x000\x82\xe5\xff'\xa0\xe35*\x82\xe2\x04
\x82\xe2\xff7\xa0\xe35:\x83\xe2\x040\x83\xe2\x000\x93\xe5\x190\x83\xe3\x000\x82\xe5\xff'\xa0\xe35*\x82\xe2\xff7\xa0\xe35:\x83\xe2\x000\x93\xe5\xf00\x83\xe3\x000\x82\xe5\xff'\xa0\xe35*\x82\xe2\xff7\xa0\xe35:\x83\xe2\x000\x93\xe5\x7f;\x83\xe3\x000\x82\xe5\xff'\xa0\xe35*\x82\xe2\xff7\xa0\xe3#b0
r <Timeout: 2 seconds>
w
$X826a,136:\xa0\xe1\x00\xd8-\xe9\x04\xb0L\xe2\xff'\xa0\xe36*\x82\xe2\xff7\xa0\xe36:\x83\xe2\x000\x93\xe5\b0\xc3\xe3\x000\x82\xe5\xff'\xa0\xe36*\x82\xe2\xff7\xa0\xe36:\x83\xe2\x000\x93\xe5\x100\xc3\xe3\x000\x82\xe5\xff\x17\xa0\xe36\x1a\x81\xe2\b\x10\x81\xe2\x000\xa0\xe1\x031\xa0\xe1\x000\x83\xe0\x03!\xa0\xe1\x020\x83\xe0\x830\xa0\xe1\x010C\xe2\x000\x81\xe5\x00\xa8\x1b\xe9\r\xc0\xa0\xe1\x00\xd8-\xe9\x04\xb0L\xe2\xff'\xa0\xe35*\x82\xe2\x04
\x82\xe2\xff7\xa0\xe35:\x83\xe2\x040\x83\xe2\x000\x93\xe5i4\xc3\xe3\xbf8\xc3\xe3?;\xc3\xe3\x000\x82\xe5\xff'\xa0\xe35*\x82\xe2\x04
\x82\xe2\xff7\xa0\xe35:\x83\xe2\x040\x83\xe2\x000\x93\xe5\x1f0\xc3\xe3\x000\x82\xe5\xff'\xa0\xe35*\x82\xe2\x04
\x82\xe2\xff7\xa0\xe35:\x83\xe2\x040\x83\xe2\x000\x93\xe5\x190\x83\xe3\x000\x82\xe5\xff'\xa0\xe35*\x82\xe2\xff7\xa0\xe35:\x83\xe2\x000\x93\xe5\xf00\x83\xe3\x000\x82\xe5\xff'\xa0\xe35*\x82\xe2\xff7\xa0\xe35:\x83\xe2\x000\x93\xe5\x7f;\x83\xe3\x000\x82\xe5\xff'\xa0\xe35*\x82\xe2\xff7\xa0\xe3#b0
r <Timeout: 2 seconds>
w
$X826a,136:\xa0\xe1\x00\xd8-\xe9\x04\xb0L\xe2\xff'\xa0\xe36*\x82\xe2\xff7\xa0\xe36:\x83\xe2\x000\x93\xe5\b0\xc3\xe3\x000\x82\xe5\xff'\xa0\xe36*\x82\xe2\xff7\xa0\xe36:\x83\xe2\x000\x93\xe5\x100\xc3\xe3\x000\x82\xe5\xff\x17\xa0\xe36\x1a\x81\xe2\b\x10\x81\xe2\x000\xa0\xe1\x031\xa0\xe1\x000\x83\xe0\x03!\xa0\xe1\x020\x83\xe0\x830\xa0\xe1\x010C\xe2\x000\x81\xe5\x00\xa8\x1b\xe9\r\xc0\xa0\xe1\x00\xd8-\xe9\x04\xb0L\xe2\xff'\xa0\xe35*\x82\xe2\x04
\x82\xe2\xff7\xa0\xe35:\x83\xe2\x040\x83\xe2\x000\x93\xe5i4\xc3\xe3\xbf8\xc3\xe3?;\xc3\xe3\x000\x82\xe5\xff'\xa0\xe35*\x82\xe2\x04
\x82\xe2\xff7\xa0\xe35:\x83\xe2\x040\x83\xe2\x000\x93\xe5\x1f0\xc3\xe3\x000\x82\xe5\xff'\xa0\xe35*\x82\xe2\x04
\x82\xe2\xff7\xa0\xe35:\x83\xe2\x040\x83\xe2\x000\x93\xe5\x190\x83\xe3\x000\x82\xe5\xff'\xa0\xe35*\x82\xe2\xff7\xa0\xe35:\x83\xe2\x000\x93\xe5\xf00\x83\xe3\x000\x82\xe5\xff'\xa0\xe35*\x82\xe2\xff7\xa0\xe35:\x83\xe2\x000\x93\xe5\x7f;\x83\xe3\x000\x82\xe5\xff'\xa0\xe35*\x82\xe2\xff7\xa0\xe3#b0
r <Timeout: 2 seconds><Timeout: 2 seconds>
w -
r <Timeout: 2 seconds>
w -
r <Timeout: 2 seconds>
...
===============================================================
-- 
________________________________________________________________________
Pierre HABRAKEN - mailto:Pierre.Habraken@imag.fr
Tél: 04 76 82 72 83 - Fax: 04 76 82 72 87
IMAG-LSR BP72 38402 SAINT MARTIN D'HERES Cedex
________________________________________________________________________

Re: [ECOS] Can't connect to remote Evaluator 7T

[Gary D. Thomas]

On Thu, 2003-02-20 at 07:28, Pierre Habraken wrote:
> Mark Salter wrote:
> > [...]
> > % stty -a </dev/ttyS0
> > speed 115200 baud; rows 0; columns 0; line = 0;
> > intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
> > eol2 = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
> > werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 5;
> > -parenb -parodd cs8 hupcl -cstopb cread clocal -crtscts
>                                                  ^^^^^^^^
> Ok, I got it : hardware control flow was enabled (crtscts instead of
> -crtscts).
> So, now the command 'target remote' sets up the connection, but
> uploading (command 'load') the program to the board fails, leaving gdb
> accepting no more keyboard input (not even ^C, I have to kill it from an
> other xterm).
> 
> I attach below the gdb trace with logging disabled and also the contents
> of the file gdblog.txt produced when logging is enabled (beginning of
> the file only) :
> 
> Anyone an idea ?
> 
> Pierre
> 
> ===============================================================
> $ arm-elf-gdb
> GNU gdb 5.2
> ...
> This GDB was configured as "--host=i686-pc-linux-gnu --target=arm-elf".
> (gdb) set remotebaud 38400
> (gdb) file guirlande
> Reading symbols from guirlande...done.
> (gdb) target remote /dev/ttyS0
> Remote debugging using /dev/ttyS0
> 0x018210a8 in ?? ()
> (gdb) load
> Loading section .text, size 0x3bec lma 0x8000
> Ignoring packet error, continuing...

This happens because you're overwriting the memory used by RedBoot.
On this platform, don't try and use any memory below 0x10000.

What sort of program are you trying to load?  How did you build it?

-- 
.--------------------------------------------------------.
|       Mind: Embedded Linux and eCos Development        |
|--------------------------------------------------------|
| Gary Thomas              email:  gary.thomas@mind.be   |
| Mind ( http://mind.be )  tel:    +1 (970) 229-1963     |
| gpg: http://www.chez-thomas.org/gary/gpg_key.asc       |
'--------------------------------------------------------'

Re: [ECOS] Can't connect to remote Evaluator 7T

[Pierre Habraken]

"Gary D. Thomas" wrote:
> [...]
> This happens because you're overwriting the memory used by RedBoot.
> On this platform, don't try and use any memory below 0x10000.
> 
> What sort of program are you trying to load?  How did you build it?

This a program I wrote myself which involves interrupt handling (timer
interrupts) for teaching purpose.
I built it using arm-elf-gcc, arm-elf-as and arm-elf-ld.
When using Angel, the load address 0x8000 (which is the default one set
up by arm-elf-ld) did not raised any problem.

Ok. So, I have to re-link the program so that its location is at 0x10000
or above.
But first I am going to learn how to tell ld what to do for obtaining
this result...

Thanks a lot to everybody for your help !

Pierre
-- 
________________________________________________________________________
Pierre HABRAKEN - mailto:Pierre.Habraken@imag.fr
Tél: 04 76 82 72 83 - Fax: 04 76 82 72 87
IMAG-LSR BP72 38402 SAINT MARTIN D'HERES Cedex
________________________________________________________________________

Re: [ECOS] Can't connect to remote Evaluator 7T

[Pierre Habraken]

Pierre Habraken wrote:
> [...]
> Ok. So, I have to re-link the program so that its location is at
> 0x10000 or above.
> But first I am going to learn how to tell ld what to do for obtaining
> this result...

Passing argument -Ttext 0x10000 to ld is ok : gdb uploads the program to
the board with success.

But now I am faced to a new problem : newlib (which is linked to my
program), and especially the C run time sartup code, uses SWI calls to
Angel (swi 0x00123456), which one has been replaced by Redboot !

Does anyone know how to tell newlib not to use Angel services ?

Pierre
--
________________________________________________________________________
Pierre HABRAKEN - mailto:Pierre.Habraken@imag.fr
Tél: 04 76 82 72 83 - Fax: 04 76 82 72 87
IMAG-LSR BP72 38402 SAINT MARTIN D'HERES Cedex
________________________________________________________________________

Re: [ECOS] Can't connect to remote Evaluator 7T

[Gary D. Thomas]

On Fri, 2003-02-21 at 01:06, Pierre Habraken wrote:
> Pierre Habraken wrote:
> > [...]
> > Ok. So, I have to re-link the program so that its location is at
> > 0x10000 or above.
> > But first I am going to learn how to tell ld what to do for obtaining
> > this result...
> 
> Passing argument -Ttext 0x10000 to ld is ok : gdb uploads the program to
> the board with success.
> 
> But now I am faced to a new problem : newlib (which is linked to my
> program), and especially the C run time sartup code, uses SWI calls to
> Angel (swi 0x00123456), which one has been replaced by Redboot !
> 
> Does anyone know how to tell newlib not to use Angel services ?

Why not just run eCos?  You'll have much more flexibility
than what you'll get with newlib.

-- 
.--------------------------------------------------------.
|       Mind: Embedded Linux and eCos Development        |
|--------------------------------------------------------|
| Gary Thomas              email:  gary.thomas@mind.be   |
| Mind ( http://mind.be )  tel:    +1 (970) 229-1963     |
| gpg: http://www.chez-thomas.org/gary/gpg_key.asc       |
'--------------------------------------------------------'

Re: [ECOS] Can't connect to remote Evaluator 7T

[Mark Salter]

>>>>> Pierre Habraken writes:

> Mark Salter wrote:
>> [...]
>> % stty -a </dev/ttyS0
>> speed 115200 baud; rows 0; columns 0; line = 0;
>> intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
>> eol2 = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
>> werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 5;
>> -parenb -parodd cs8 hupcl -cstopb cread clocal -crtscts
>                                                  ^^^^^^^^
> Ok, I got it : hardware control flow was enabled (crtscts instead of
> -crtscts).

Okay. I'm seeing a different connection problem, then.

> So, now the command 'target remote' sets up the connection, but
> uploading (command 'load') the program to the board fails, leaving gdb
> accepting no more keyboard input (not even ^C, I have to kill it from an
> other xterm).

> I attach below the gdb trace with logging disabled and also the contents
> of the file gdblog.txt produced when logging is enabled (beginning of
> the file only) :

> Anyone an idea ?

> Pierre

> ===============================================================
> $ arm-elf-gdb
> GNU gdb 5.2
> ...
> This GDB was configured as "--host=i686-pc-linux-gnu --target=arm-elf".
> (gdb) set remotebaud 38400
> (gdb) file guirlande
> Reading symbols from guirlande...done.
> (gdb) target remote /dev/ttyS0
> Remote debugging using /dev/ttyS0
> 0x018210a8 in ?? ()
> (gdb) load
> Loading section .text, size 0x3bec lma 0x8000
                                         ^^^^^^
This seems pretty low in memory. Maybe you are overwriting memory used
by the stub.

--Mark

Re: [ECOS] Can't connect to remote Evaluator 7T

[Andrew Lunn]

> Loading section .text, size 0x3bec lma 0x8000

I think you have used the wrong startup type.

The ROM startup uses:

SECTIONS
{
    SECTIONS_BEGIN
    CYG_LABEL_DEFN(__reserved_bootmon) = 0x1800000; . = CYG_LABEL_DEFN(__reserved_bootmon) + 0x
20000;
    SECTION_rom_vectors (rom, ALIGN (0x8), LMA_EQ_VMA)
    SECTION_text (rom, ALIGN (0x1), LMA_EQ_VMA)
    SECTION_fini (rom, ALIGN (0x4), LMA_EQ_VMA)
    SECTION_rodata (rom, ALIGN (0x4), LMA_EQ_VMA)
    SECTION_rodata1 (rom, ALIGN (0x4), LMA_EQ_VMA)
    SECTION_fixup (rom, ALIGN (0x4), LMA_EQ_VMA)
    SECTION_gcc_except_table (rom, ALIGN (0x4), LMA_EQ_VMA)
    SECTION_fixed_vectors (ram, 0x20, LMA_EQ_VMA)
    SECTION_data (ram, 0x8000, FOLLOWING (.gcc_except_table))
    SECTION_bss (ram, ALIGN (0x4), LMA_EQ_VMA)
    CYG_LABEL_DEFN(__heap1) = ALIGN (0x8);
    SECTIONS_END
}


You see that the data section goes at address 0x8000. Im assuming you
have a ROM redboot. So its data section is at the same address you are
downloading your application.

The RAM startup code uses this layout:

SECTIONS
{
    SECTIONS_BEGIN
    SECTION_fixed_vectors (ram, 0x20, LMA_EQ_VMA)
    SECTION_rom_vectors (ram, 0x10000, LMA_EQ_VMA)
    SECTION_text (ram, ALIGN (0x4), LMA_EQ_VMA)
    SECTION_fini (ram, ALIGN (0x4), LMA_EQ_VMA)
    SECTION_rodata (ram, ALIGN (0x4), LMA_EQ_VMA)
    SECTION_rodata1 (ram, ALIGN (0x4), LMA_EQ_VMA)
    SECTION_fixup (ram, ALIGN (0x4), LMA_EQ_VMA)
    SECTION_gcc_except_table (ram, ALIGN (0x4), LMA_EQ_VMA)
    SECTION_data (ram, ALIGN (0x4), LMA_EQ_VMA)
    SECTION_bss (ram, ALIGN (0x4), LMA_EQ_VMA)
    CYG_LABEL_DEFN(__heap1) = ALIGN (0x8);
    SECTIONS_END
}

Notice that rom_vectors section goes at 0x10000, and everythig else
follows that. 

Make sure your build is a RAM build. You may need to delete your work
tree and start again.

     Andrew

Re: [ECOS] Can't connect to remote Evaluator 7T

[Mark Salter]

>>>>> Pierre Habraken writes:

> Here is the contents of gdblog.txt :
> w +$Hc-1#09
> r <Timeout: 2 seconds>
> w $Hc-1#09
> r <Timeout: 2 seconds>
> w $Hc-1#09
> r <Timeout: 2 seconds>
> w $Hc-1#09
> r <Timeout: 2 seconds><Timeout: 2 seconds>
> w -
> r <Timeout: 2 seconds>
> w -
> r <Timeout: 2 seconds>
> w -+$qC#b4
> r <Timeout: 2 seconds>
> w $qC#b4
> r <Timeout: 2 seconds>
> w $qC#b4
> r <Timeout: 2 seconds>
> w $qC#b4
> r <Timeout: 2 seconds><Timeout: 2 seconds>
> w -
> r <Timeout: 2 seconds>
> w -
> r <Timeout: 2 seconds>
> w -+$qOffsets#4b
> r <Timeout: 2 seconds>
> w $qOffsets#4b
> r <Timeout: 2 seconds>
> w $qOffsets#4b
> r <Timeout: 2 seconds>
> w $qOffsets#4b
> r <Timeout: 2 seconds><Timeout: 2 seconds>
> w -
> r <Timeout: 2 seconds>
> w -
> r <Timeout: 2 seconds>
> w -+
> End of log

> What is strange is that if I quit gdb and then launch kermit at once
> without resetting the board, then redboot is there responding to
> commands such as 'version'. It looks like if redboot is prepared to
> execute basic commands but not to talk to gdb...
> About the serial settings, I did not find any gdb command allowing to
> change anything but the baudrate. I know that the speed is correct
> (38400) but have no idea concerning the others parameters (parity,
> etc.).


Hmm, this is all very familiar. Are you using a linux host? What version?
I have seen this intermittantly on my RH 7.3 box. I cannot reproduce it
on a windows or Solaris box. It looks like a serial driver problem, but
I haven't had time to track it down...

--Mark