[ECOS] More information on crash with CVS sources

[ECOS] More information on crash with CVS sources

[Lewin A.R.W. Edwards]

Hi all,

By stepping the program, I've subsequently found that my crash problem
(with anoncvs app running on top of 1.3.1 stubs) occurs when the app
first tries to printf something. I guess I can fix this by disabling
virtual vectors in the app?

But it still doesn't explain why I'm not able to run an app on top of
the anoncvs-built stubs.


-- Lewin A.R.W. Edwards (Embedded Engineer)              * Linux system
Work:     http://www.digi-frame.com/
Personal: http://www.larwe.com/ and http://www.zws.com/

Re: [ECOS] More information on crash with CVS sources

[Jonathan Larmour]

"Lewin A.R.W. Edwards" wrote:
> 
> Hi all,
> 
> By stepping the program, I've subsequently found that my crash problem
> (with anoncvs app running on top of 1.3.1 stubs) occurs when the app
> first tries to printf something. I guess I can fix this by disabling
> virtual vectors in the app?
> 
> But it still doesn't explain why I'm not able to run an app on top of
> the anoncvs-built stubs.

Jesper just checked in a whole bunch of changes to do with virtual vectors.
When does your anoncvs checkout date from?

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] More information on crash with CVS sources

[Lewin A.R.W. Edwards]

Hi Jonathan,

> > By stepping the program, I've subsequently found that my crash problem
> > (with anoncvs app running on top of 1.3.1 stubs) occurs when the app
> > first tries to printf something. I guess I can fix this by disabling
> > virtual vectors in the app?
> > But it still doesn't explain why I'm not able to run an app on top of
> > the anoncvs-built stubs.
>
>Jesper just checked in a whole bunch of changes to do with virtual vectors.
>When does your anoncvs checkout date from?

It's from... hmmm... last Friday or Thursday maybe (I'm booted to Windows 
right now... can't check). I'll update tomorrow morning then look into a 
patch Gary sent me.

However, in further news, I built a little test proglet that consists of 
just a cyg_user_start that does a printf [and nothing else] and a main() 
that also does a printf.

In 1.3.1, it is seemingly not necessary to explicitly create and start a 
thread. cyg_user_start enables interrupts, and then control passes to 
main(). So my program at the moment runs in main() [since it was ported 
from a different OS].

When I compile the above test prog with anoncvs everything, I get the 
printf from cyg_user_start but not the one from main; after the printf("hi 
from cyg_user_start") I get an exception at 0xfffffffc. So I assume the 
1.3.1 behavior I describe above is no longer true and that I must 
explicitly start a thread for my main application task.

It doesn't completely explain why I can't get the anoncvs app to run on 
anoncvs stubs, though - I never even get the "new thread 0 created" message 
or the cyg_user_start message. Bizarre.
=== Lewin A.R.W. Edwards (Embedded Engineer)
Work: http://www.digi-frame.com/
Personal: http://www.zws.com/ and http://www.larwe.com/

"Und setzet ihr nicht das Leben ein,
Nie wird euch das Leben gewonnen sein."

Re: [ECOS] More information on crash with CVS sources

[Jonathan Larmour]

"Lewin A.R.W. Edwards" wrote:
> 
> However, in further news, I built a little test proglet that consists of
> just a cyg_user_start that does a printf [and nothing else] and a main()
> that also does a printf.
> 
> In 1.3.1, it is seemingly not necessary to explicitly create and start a
> thread. cyg_user_start enables interrupts, and then control passes to
> main(). So my program at the moment runs in main() [since it was ported
> from a different OS].
> 
> When I compile the above test prog with anoncvs everything, I get the
> printf from cyg_user_start but not the one from main; after the printf("hi
> from cyg_user_start") I get an exception at 0xfffffffc. So I assume the
> 1.3.1 behavior I describe above is no longer true and that I must
> explicitly start a thread for my main application task.

There is stuff in the CYGPKG_LIBC_STARTUP package to do this for you - it
provides a default cyg_user_start() that will create (and resume) a thread
that will call main(). This differs from v1.3.1 because this used to happen
in cyg_package_start(). But this wasn't right because it polluted the
design, and meant that people who weren't interested in having their own
main(), and instead wanted to just write their own eCos program (which
would therefore include a cyg_user_start() entry point) would still get a
main() thread created. This way they don't.

You don't need to start a thread by hand. But if you provide your _own_
cyg_user_start() then you can instead call "cyg_iso_c_start()" from your
cyg_user_start(), since the default cyg_user_start() isn't being run.

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] More information on crash with CVS sources

[Lewin A.R.W. Edwards]

Hi Jonathan (and Gary),

>There is stuff in the CYGPKG_LIBC_STARTUP package to do this for you - it
>provides a default cyg_user_start() that will create (and resume) a thread
>that will call main(). This differs from v1.3.1 because this used to happen

Once I upgraded to redboot on the host, then main() started getting called 
again, so that is OK. I need to do some more reading. I don't fully 
understand yet how to compile the current version to work with stubs (as I 
think I don't want to use redboot). I'm also getting close to the point 
where I will have real hardware, so I'll need to port it.

The reason I've been working on several things at once is to get a feel of 
how large the app will wind up, so that I could get my ROM and RAM budgets. 
The networking layer takes up a vast amount of RAM, I'd like to try 
decreasing that if I can.

I also need to read more on the network layer to better understand how it 
all fits together (networking internals are not my forte).

Thanks for all the help; at the moment the ball is in my court and I have a 
lot I can do without bothering you guys on the list :)

=== Lewin A.R.W. Edwards (Embedded Engineer)
Work: http://www.digi-frame.com/
Personal: http://www.zws.com/ and http://www.larwe.com/

"Und setzet ihr nicht das Leben ein,
Nie wird euch das Leben gewonnen sein."