[ECOS] updated to new eCos version, asserts when first thread is resumed

[ECOS] updated to new eCos version, asserts when first thread is resumed

[Nathan French]

We just updated from eCos (pro) 2.0.91 to 3.0.9.1.  What I'm seeing is
that during cyg_user_start(), as soon as we create a thread and
cyg_thread_resume() it the kernel asserts in
Cyg_Scheduler_Implementation::add_thread().

The assert it is hitting is "Idle thread vanished!!!" but I believe it
is due to the queue_map member of the scheduler not being initialized
(it's a null pointer).  I'm admittedly a little confused as to how
exactly the kernel starts up and constructs the scheduler.

After some googling I became confused about whether I needed to call
cyg_scheduler_start() and if so, where.  I tried calling this prior to
resuming the thread but it failed in a very similar way (different
assert, but same root cause).  I don't believe there is anything wrong
with our application code but thought perhaps we had been doing
something wrong all along and the newer eCos version enforces something
now... but I haven't found any evidence of that.

Any ideas?  Thanks in advance.

N.F.


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

Re: [ECOS] updated to new eCos version, asserts when first thread is resumed

[Gary Thomas]

On 03/14/2011 05:46 PM, Nathan French wrote:
> We just updated from eCos (pro) 2.0.91 to 3.0.9.1.  What I'm seeing is
> that during cyg_user_start(), as soon as we create a thread and
> cyg_thread_resume() it the kernel asserts in
> Cyg_Scheduler_Implementation::add_thread().
>
> The assert it is hitting is "Idle thread vanished!!!" but I believe it
> is due to the queue_map member of the scheduler not being initialized
> (it's a null pointer).  I'm admittedly a little confused as to how
> exactly the kernel starts up and constructs the scheduler.
>
> After some googling I became confused about whether I needed to call
> cyg_scheduler_start() and if so, where.  I tried calling this prior to
> resuming the thread but it failed in a very similar way (different
> assert, but same root cause).  I don't believe there is anything wrong
> with our application code but thought perhaps we had been doing
> something wrong all along and the newer eCos version enforces something
> now... but I haven't found any evidence of that.
>
> Any ideas?  Thanks in advance.

eCos(pro) ==> ask eCosCentric

This list is for help with the public version of eCos

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

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

[ECOS] Linking Kernel to fast RAM?

[Richard Rauch]

Hi All,
 
I'm working on an ARM9 microcontroller with different memories. Beside the
external Memory (DDR) the controller has an OnChip Memory with no waitstates
(TCM)
So my idea is to link time critical kernel modules (like scheduler, event
handling,..) to this very fast memory in order to have performance
improvements.
But I do not want to put drivers to this memory, because it is too small for
the complete eCos Library.
Are there already defines different sections for the modules of eCos?  Is it
possible to map the kernel to another memory section by editing the linker
files only? 
 
Thanks 
Richard


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