Henry Yu | 1 Nov 2005 06:58

Re: GDB Problem

Andrew
    Thank you so much for taking the time to reply me, follow you direction, I use serial port to connect boards,
in gdb mode I type:
"(gdb) set remotebaud 115200"
"(gdb) target remote com1"
but some error show me:
"Remote debugging using com1"
"couldn't establish connection to remote target"
"cannot access memory at address 0xcca7cd2a"

Please give me a hand!

Thank you!

Henry,
Sincerely

--- Andrew Lunn <andrew <at> lunn.ch> wrote:

From: Andrew Lunn <andrew <at> lunn.ch>
Date: Mon, 31 Oct 2005 06:36:47 +0100
To: Henry Yu <henry <at> sigpro.com>
Cc: ecos-discuss <at> ecos.sourceware.org
Subject: Re: [ECOS] GDB Problem

On Sun, Oct 30, 2005 at 06:48:25PM -0800, Henry Yu wrote:
> Hello,
>      Now  I porting RedBoot from Mips 4kc to TI's TNETV 1060, I
> can see "RedBoot>". When I type "fconfig -l" it list:
> 
(Continue reading)

Andrew Lunn | 1 Nov 2005 08:46
Picon

Re: GDB Problem

On Mon, Oct 31, 2005 at 09:58:12PM -0800, Henry Yu wrote:
> Andrew
>     Thank you so much for taking the time to reply me, follow you direction, I use serial port to connect boards,
in gdb mode I type:
> "(gdb) set remotebaud 115200"
> "(gdb) target remote com1"
> but some error show me:
> "Remote debugging using com1"
> "couldn't establish connection to remote target"
> "cannot access memory at address 0xcca7cd2a"

Does your serial cable work OK? 

try doing

set remotedebug on

and see if there is any communication between the host and the target.

        Andrew

--

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Dirk Husemann | 1 Nov 2005 11:25
Picon
Favicon
Gravatar

Re: Serial support for arm board

Dave B. Sharp wrote:

>I've compiled and done everything in link you sent: 
>arm-gdb main
>target remore ....
>load ...
>continue
> continuing
>
>when I do the continue it seem to hang waiting for the
>target to connect. When I <cntl-c> out it reports
>interupted while waiting for the program
>Give up (and stop debugging it?) (y or n)
> Am I missing something? Do I need to write a stub for
>my program or is the one in Redboot sufficient?
>  
>
hmm...not sure whether you did that, but did you set a breakpoint? at 
least from the summary above it looks like you didn't...

    dirk

>  Cheers
>   Dave
>
>--- Andrew Lunn <andrew <at> lunn.ch> wrote:
>
>  
>
>>On Thu, Oct 27, 2005 at 03:33:09PM -0400, Dave B.
(Continue reading)

Stefan Sommerfeld | 1 Nov 2005 13:28
Picon

Re: ISR to DSR delay?

Hi,

Progress update:

I'm still searching, but find a strange thing: In the irq_end routine 
(intr.cxx:323) there's a Cyg_Scheduler::unlock(), which should run pending 
dsr's. I think there're to possible things which this function could to:
Decrease the scheduler lock and return and Decrease and call unlock_inner() 
to call pending dsr's. What i see is that this ::unlock() take sometimes 
more than 6ms, but the unlock_inner() is always fast (some microseconds). 
So what could be the cause? Maybe a context switch while unlocking? Any 
hints?

Bye...

----- Original Message ----- 
From: "Andrew Lunn" <andrew <at> lunn.ch>
To: "Stefan Sommerfeld" <sommerfeld <at> mikrom.de>
Cc: <ecos-discuss <at> ecos.sourceware.org>
Sent: Donnerstag, 13. Oktober 2005 14:14
Subject: Re: [ECOS] ISR to DSR delay?

> On Thu, Oct 13, 2005 at 02:42:58PM +0200, Stefan Sommerfeld wrote:
>> Hi,
>>
>> I working with latest eCos on a XScale system and i noticed a very high
>> delay between the ISR and the corresponding after some time. The system 
>> is
>> not idle and does a lot of things (including multiple threads and 
>> irq's). I
(Continue reading)

Dave B. Sharp | 1 Nov 2005 14:14
Picon
Favicon

Re: Serial support for arm board

No, but even if I had would that have not been cleared
with a reboot?
   Dave

--- Dirk Husemann <hud <at> zurich.ibm.com> wrote:

> Dave B. Sharp wrote:
> 
> >I've compiled and done everything in link you sent:
> 
> >arm-gdb main
> >target remore ....
> >load ...
> >continue
> > continuing
> >
> >when I do the continue it seem to hang waiting for
> the
> >target to connect. When I <cntl-c> out it reports
> >interupted while waiting for the program
> >Give up (and stop debugging it?) (y or n)
> > Am I missing something? Do I need to write a stub
> for
> >my program or is the one in Redboot sufficient?
> >  
> >
> hmm...not sure whether you did that, but did you set
> a breakpoint? at 
> least from the summary above it looks like you
> didn't...
(Continue reading)

Dirk Husemann | 1 Nov 2005 14:19
Picon
Favicon
Gravatar

Re: Serial support for arm board

Dave B. Sharp wrote:

>No, but even if I had would that have not been cleared
>with a reboot?
>  
>
no, GDB will set the breakpoint on loading. so, if you staid connected, 
did a reset of the board and then reloaded the image, you'd end up with 
the breakpoint set again.

what i usually do is set breakpoints at cyg_user_start and 
cyg_assert_fail before doing the continue.

    cheers,
    dirk

>   Dave
> 
>--- Dirk Husemann <hud <at> zurich.ibm.com> wrote:
>
>  
>
>>Dave B. Sharp wrote:
>>
>>    
>>
>>>I've compiled and done everything in link you sent:
>>>      
>>>
>>>arm-gdb main
(Continue reading)

Alex Schuilenburg | 1 Nov 2005 15:27
Favicon

Re: ecos test infrastructure

Andrew Lunn wrote:
>>Running a single test program from within gdb works fine.
>>Would it be possible with the current infrastructure to run a
>>testsuite on the target system without using the graphical configtool
>>and report the results to a database instead? [*]
>>
>>Is there any more documentation about the testing infrastructure
>>(e.g.~about the use of dejagnu) than what I found in user-, ref-, and
>>component writers guide and the above described README.host?
[...]
>>[*] I guess the test farm at ecoscentric must do something similar...
> 
> 
> I've never seen eCosCentric's code, since it is there interlectual
> property, but i guess it does.

It does :-)  Currently at 5,658,576 tests executed and counting with
results easily searchable and selectable by our engineers.

OOI, while the docs refer to dejagnu, while at Cynus and later planet
Red Hat, it became clear to us that while dejagnu is fine for driving
gcc and gdb tests, unfortunately it does not cut the mustard when it
comes to driving eCos tests. Generally, we have found that the
configtool testing capability fulfils the requirements of most
developers whose use anoncvs so have not taken that further.

As for our test farm, eCosCentric have spent a significant amount of
effort and investment developing a fully-automated eCos testing
infrastructure to help us produce eCosPro. It puts eCos through its
paces in ways that the configtool cannot but requires a similar
(Continue reading)

Will Wagner | 2 Nov 2005 13:12
Favicon

sntp question

I have been looking at the sntp code in eCos.

In the docs it talks about starting the sntp thread automatically if the 
dhcp server includes information about ntp servers. I have searched the 
source and I can't find any code that does this.

Are the docs correct and if so where is the code?

Thanks,

Will
-- 
------------------------------------------------------------------------
Will Wagner                                     will_wagner <at> carallon.com
Senior Project Engineer                        Office Tel: 0207 371 2032
Carallon Ltd, Studio G20, Shepherds Building, Rockley Rd, London W14 0DA
------------------------------------------------------------------------

--

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Scott Bailie | 2 Nov 2005 15:56
Picon

Problem building from anon CVS

Hi, 

I’m having problems building with the latest code I downloaded from the anon
CVS. Previously I used the very old code & utils that were included in
Massa’s book. I simply wanted to get acquainted with eCos following his
tutorial. Next I grabbed the latest from the repository and using the eCos
Config tool v2.11 can no longer build. I get the following error:

/ecos-c/ecos/packages/hal/i386/pc/current/src/plf_misc.c: In function
`hal_platform_init':
/ecos-c/ecos/packages/hal/i386/pc/current/src/plf_misc.c:129: parse error
before `lo'
/ecos-c/ecos/packages/hal/i386/pc/current/src/plf_misc.c:131: `lo'
undeclared (first use in this function)
/ecos-c/ecos/packages/hal/i386/pc/current/src/plf_misc.c:131: (Each
undeclared identifier is reported only once
/ecos-c/ecos/packages/hal/i386/pc/current/src/plf_misc.c:131: for each
function it appears in.)
/ecos-c/ecos/packages/hal/i386/pc/current/src/plf_misc.c:132: `hi'
undeclared (first use in this function)

I’ve searched the mailing list with no luck and I apologize if this was
explained and I missed it.  I’m running on a WINXP platform with a recent
version of cygwin I just downloaded. Any thoughts as to what is going wrong?

_________________
Scott Bailie
MIT LINCOLN LAB
781.981.4140

(Continue reading)

Gary Thomas | 2 Nov 2005 16:03
Favicon

Re: Problem building from anon CVS

On Wed, 2005-11-02 at 09:56 -0500, Scott Bailie wrote:
> Hi, 
> 
> I’m having problems building with the latest code I downloaded from the anon
> CVS. Previously I used the very old code & utils that were included in
> Massa’s book. I simply wanted to get acquainted with eCos following his
> tutorial. Next I grabbed the latest from the repository and using the eCos
> Config tool v2.11 can no longer build. I get the following error:
> 
> /ecos-c/ecos/packages/hal/i386/pc/current/src/plf_misc.c: In function
> `hal_platform_init':
> /ecos-c/ecos/packages/hal/i386/pc/current/src/plf_misc.c:129: parse error
> before `lo'
> /ecos-c/ecos/packages/hal/i386/pc/current/src/plf_misc.c:131: `lo'
> undeclared (first use in this function)
> /ecos-c/ecos/packages/hal/i386/pc/current/src/plf_misc.c:131: (Each
> undeclared identifier is reported only once
> /ecos-c/ecos/packages/hal/i386/pc/current/src/plf_misc.c:131: for each
> function it appears in.)
> /ecos-c/ecos/packages/hal/i386/pc/current/src/plf_misc.c:132: `hi'
> undeclared (first use in this function)
> 
> I’ve searched the mailing list with no luck and I apologize if this was
> explained and I missed it.  I’m running on a WINXP platform with a recent
> version of cygwin I just downloaded. Any thoughts as to what is going wrong?

This looks like a problem with setup - are you sure you're not
getting any other errors/warnings before this?  In particular,
this error says that the eCos standard type "cyg_uint8" is not
defined, which would imply that there was a problem including
(Continue reading)


Gmane