[ECOS] program doesn't work with new redboot

[ECOS] program doesn't work with new redboot

[Trenton D. Adams]

My program won't work with the new redboot I just compiled.  It does the
following.

$ arm-elf-gdb.exe -nw RigSystem.exe
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=i686-pc-cygwin --target=arm-elf"...
(gdb) set remotebaud 115200
(gdb) target remote com1
Remote debugging using com1
0xe0006630 in ?? ()
(gdb) load
Loading section .rom_vectors, size 0x40 lma 0x20000
Loading section .text, size 0x389c0 lma 0x20040
Loading section .rodata, size 0x1a1b8 lma 0x58a00
Loading section .data, size 0x1194 lma 0x72bb8
Start address 0x20040 , load size 343372
Ignoring packet error, continuing...
Transfer rate: 80793 bits/sec, 306 bytes/write.
(gdb) cont
Continuing.
Ignoring packet error, continuing...
Interrupted while waiting for the program.
Give up (and stop debugging it)? (y or n) y
(gdb)


Any ideas?

Trenton D. Adams
Extreme Engineering
#17, 6025 - 12 St. SE
Calgary, Alberta, Canada
T2H 2K1

Phone: 403 640 9494 ext-208
Fax: 403 640 9599

http://www.extremeeng.com

Re: [ECOS] program doesn't work with new redboot

[Jonathan Larmour]

"Trenton D. Adams" wrote:
> 
> My program won't work with the new redboot I just compiled.  It does the
> following.
> 
> $ arm-elf-gdb.exe -nw RigSystem.exe
> 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=i686-pc-cygwin --target=arm-elf"...
> (gdb) set remotebaud 115200
> (gdb) target remote com1
> Remote debugging using com1
> 0xe0006630 in ?? ()
> (gdb) load
> Loading section .rom_vectors, size 0x40 lma 0x20000
> Loading section .text, size 0x389c0 lma 0x20040
> Loading section .rodata, size 0x1a1b8 lma 0x58a00
> Loading section .data, size 0x1194 lma 0x72bb8
> Start address 0x20040 , load size 343372
> Ignoring packet error, continuing...

Just a download error?

> Transfer rate: 80793 bits/sec, 306 bytes/write.
> (gdb) cont
> Continuing.
> Ignoring packet error, continuing...
> Interrupted while waiting for the program.
> Give up (and stop debugging it)? (y or n) y
> (gdb)
> 
> Any ideas?

set debug remote 1

Or just... try again, it could have just been a flaky download, or is it
repeatable.

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine

RE: [ECOS] program doesn't work with new redboot

[Trenton D. Adams]

No, it's not likely a download error.  I tried it several times.

Set debug remote 1 makes a lot of stuff come up.  It's crazy.

-----Original Message-----
From: ecos-discuss-owner@sources.redhat.com
[ mailto:ecos-discuss-owner@sources.redhat.com ] On Behalf Of Jonathan
Larmour
Sent: August 10, 2001 3:28 PM
To: Trenton D. Adams
Cc: 'eCos Disuss'
Subject: Re: [ECOS] program doesn't work with new redboot


"Trenton D. Adams" wrote:
> 
> My program won't work with the new redboot I just compiled.  It does 
> the following.
> 
> $ arm-elf-gdb.exe -nw RigSystem.exe
> 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=i686-pc-cygwin --target=arm-elf"...
> (gdb) set remotebaud 115200
> (gdb) target remote com1
> Remote debugging using com1
> 0xe0006630 in ?? ()
> (gdb) load
> Loading section .rom_vectors, size 0x40 lma 0x20000
> Loading section .text, size 0x389c0 lma 0x20040
> Loading section .rodata, size 0x1a1b8 lma 0x58a00
> Loading section .data, size 0x1194 lma 0x72bb8
> Start address 0x20040 , load size 343372
> Ignoring packet error, continuing...

Just a download error?

> Transfer rate: 80793 bits/sec, 306 bytes/write.
> (gdb) cont
> Continuing.
> Ignoring packet error, continuing...
> Interrupted while waiting for the program.
> Give up (and stop debugging it)? (y or n) y
> (gdb)
> 
> Any ideas?

set debug remote 1

Or just... try again, it could have just been a flaky download, or is it
repeatable.

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223)
271062 Maybe this world is another planet's Hell -Aldous Huxley ||
Opinions==mine

Re: [ECOS] program doesn't work with new redboot

[Jonathan Larmour]

"Trenton D. Adams" wrote:
> 
> No, it's not likely a download error.  I tried it several times.
> 
> Set debug remote 1 makes a lot of stuff come up.  It's crazy.

Try "set remote binary 0" first to stop it outputting non-text characters.
Or possibly instead use "set remotelogfile" to put it straight to a file,
and analyze the traffic afterwards.

Generally if you get a packet error in a load it implies you are
overwriting the RAM area of RedBoot/GDB stubs alreay running. Normally
0x20000 is enough, but perhaps do an "arm-elf-objdump -h" of your Redboot
executable it is running to check it isn't going above that.

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine

RE: [ECOS] program doesn't work with new redboot

[Trenton D. Adams]

I recompiled redboot again, and I don't get the ignoring packet error.

My program still locks up though.  I'm going to try and figure it out
myself first.  I do have a question though.

Is there any way that compilation options for redboot would affect the
running of my eCos program?

-----Original Message-----
From: ecos-discuss-owner@sources.redhat.com
[ mailto:ecos-discuss-owner@sources.redhat.com ] On Behalf Of Jonathan
Larmour
Sent: Friday, August 10, 2001 3:28 PM
To: Trenton D. Adams
Cc: 'eCos Disuss'
Subject: Re: [ECOS] program doesn't work with new redboot


"Trenton D. Adams" wrote:
> 
> My program won't work with the new redboot I just compiled.  It does
the
> following.
> 
> $ arm-elf-gdb.exe -nw RigSystem.exe
> 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=i686-pc-cygwin --target=arm-elf"...
> (gdb) set remotebaud 115200
> (gdb) target remote com1
> Remote debugging using com1
> 0xe0006630 in ?? ()
> (gdb) load
> Loading section .rom_vectors, size 0x40 lma 0x20000
> Loading section .text, size 0x389c0 lma 0x20040
> Loading section .rodata, size 0x1a1b8 lma 0x58a00
> Loading section .data, size 0x1194 lma 0x72bb8
> Start address 0x20040 , load size 343372
> Ignoring packet error, continuing...

Just a download error?

> Transfer rate: 80793 bits/sec, 306 bytes/write.
> (gdb) cont
> Continuing.
> Ignoring packet error, continuing...
> Interrupted while waiting for the program.
> Give up (and stop debugging it)? (y or n) y
> (gdb)
> 
> Any ideas?

set debug remote 1

Or just... try again, it could have just been a flaky download, or is it
repeatable.

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223)
271062
Maybe this world is another planet's Hell -Aldous Huxley ||
Opinions==mine

Re: [ECOS] program doesn't work with new redboot

[Jonathan Larmour]

"Trenton D. Adams" wrote:
> 
> I recompiled redboot again, and I don't get the ignoring packet error.
> 
> My program still locks up though.  I'm going to try and figure it out
> myself first.  I do have a question though.
> 
> Is there any way that compilation options for redboot would affect the
> running of my eCos program?

Not in general.

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine

RE: [ECOS] program doesn't work with new redboot

[Trenton D. Adams]

What about the clock speed of the processor?  Default settings for the
EDB7111 is 73.728MHz.  So, I assume that redboot must be set to this
since the Redboot user guide seems to use mostly default values.  Is
this likely to cause a problem if I need my eCos program to run at
18.432MHz?  But, I would think that since eCos is the last system to
start up, the CPU should be set to 18.432MHz instead of what redboot
wanted it to be.

I think I'm just grasping for solutions to my PCMCIA controller problem!
lol  I haven't worked on it in quite awhile because I think I need more
information.  It's out of production, what do you expect!!  It doesn't
look very promising, that's for damn sure.

-----Original Message-----
From: ecos-discuss-owner@sources.redhat.com
[ mailto:ecos-discuss-owner@sources.redhat.com ] On Behalf Of Jonathan
Larmour
Sent: Monday, August 13, 2001 10:53 AM
To: Trenton D. Adams
Cc: 'eCos Disuss'
Subject: Re: [ECOS] program doesn't work with new redboot


"Trenton D. Adams" wrote:
> 
> I recompiled redboot again, and I don't get the ignoring packet error.
> 
> My program still locks up though.  I'm going to try and figure it out
> myself first.  I do have a question though.
> 
> Is there any way that compilation options for redboot would affect the
> running of my eCos program?

Not in general.

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223)
271062
Maybe this world is another planet's Hell -Aldous Huxley ||
Opinions==mine

Re: [ECOS] program doesn't work with new redboot

[Jonathan Larmour]

"Trenton D. Adams" wrote:
> 
> What about the clock speed of the processor?

Oh you meant *eCos* configuration options when you said "compilation
options". I thought you meant the compile line options. In that case, "yes"
:-).

> Default settings for the
> EDB7111 is 73.728MHz.  So, I assume that redboot must be set to this
> since the Redboot user guide seems to use mostly default values.  Is
> this likely to cause a problem if I need my eCos program to run at
> 18.432MHz?  But, I would think that since eCos is the last system to
> start up, the CPU should be set to 18.432MHz instead of what redboot
> wanted it to be.

I don't think RedBoot uses the timer for anything, so porbably okay.
 
Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine

RE: [ECOS] program doesn't work with new redboot

[Trenton D. Adams]

Sorry, wrong terminology! :)

It's not the timer I'm worried about.  If the CL-PS6700 does not run at
a constant 18.432MHz, it will not work properly.  The cycle timing will
be off and I won't be able to communicate with the PC-card.  

So, with this new information, is it possible that Redboot's clock rate
could interfere with the eCos program?

-----Original Message-----
From: jlarmour@cambridge.redhat.com
[ mailto:jlarmour@cambridge.redhat.com ] On Behalf Of Jonathan Larmour
Sent: Monday, August 13, 2001 2:28 PM
To: Trenton D. Adams
Cc: 'eCos Disuss'
Subject: Re: [ECOS] program doesn't work with new redboot


"Trenton D. Adams" wrote:
> 
> What about the clock speed of the processor?

Oh you meant *eCos* configuration options when you said "compilation
options". I thought you meant the compile line options. In that case,
"yes"
:-).

> Default settings for the
> EDB7111 is 73.728MHz.  So, I assume that redboot must be set to this
> since the Redboot user guide seems to use mostly default values.  Is
> this likely to cause a problem if I need my eCos program to run at
> 18.432MHz?  But, I would think that since eCos is the last system to
> start up, the CPU should be set to 18.432MHz instead of what redboot
> wanted it to be.

I don't think RedBoot uses the timer for anything, so porbably okay.
 
Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223)
271062
Maybe this world is another planet's Hell -Aldous Huxley ||
Opinions==mine

Re: [ECOS] program doesn't work with new redboot

[Mark Salter]

>>>>> Trenton D Adams writes:

> My program won't work with the new redboot I just compiled.  It does the
> following.

> $ arm-elf-gdb.exe -nw RigSystem.exe
> 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=i686-pc-cygwin --target=arm-elf"...
> (gdb) set remotebaud 115200
> (gdb) target remote com1
> Remote debugging using com1
> 0xe0006630 in ?? ()
> (gdb) load
> Loading section .rom_vectors, size 0x40 lma 0x20000
> Loading section .text, size 0x389c0 lma 0x20040
> Loading section .rodata, size 0x1a1b8 lma 0x58a00
> Loading section .data, size 0x1194 lma 0x72bb8
> Start address 0x20040 , load size 343372
> Ignoring packet error, continuing...
> Transfer rate: 80793 bits/sec, 306 bytes/write.

Because you get the "Start address..." message, the download of code
was successful. The only thing that happens between that message and
the "Transfer rate..." message is the setting of the PC. That register
setting packet must be the one that gets the packet error. The
"Ignoring packet error..." message could be the result of any number
of problems receiving a packet. After sending a set register  packet,
GDB expects the target to respond with an "OK" packet. Presumably, it
is this OK packet (or perhaps lack of it) that is causing the problem.
Turning on remote protocol debug is the best way to start tracking
down these sorts of problems. So, turn on debugging with:

  (gdb) set remotedebug 1

or with newer GDBs:

  (gdb) set debug remote 1

Post the last bit of the debug output from the load command and
we'll help you interpret it. You'll get a bunch of stuff from
the load data, but the interesting part for this problem will
start with GDB sending the "$P" packet to set the pc.

--Mark