RE: [ECOS] Initialization routines take too long?

RE: [ECOS] Initialization routines take too long?

[Fabrice Gautier]

> -----Original Message-----
> From: Grant Edwards [ mailto:grante@visi.com ]
> Subject: Re: [ECOS] Initialization routines take too long?
> 
> 
> On Fri, Nov 10, 2000 at 11:57:05AM -0800, Fabrice Gautier wrote:
> 
> > > It seems that if my first 10ms timer tick occurs before system
> > > initialization is complete, something gets corrupted and the
> > > system crashes in various different ways.
> > 
> > Why should your timer be initialized before everything it needs is
> > initialized?
> 
> I'm not sure what you mean.  The timer doesn't need anything
> else to be initialized before it is initialized.

I meant that maybe your timer IRQ handler used some classes (Counter, Alarm
maybe...) which constructor had not been called before your handler is
called. 
 
> > Maybe it's a problem in the constructors priority order.
> 
> I think it's more likely a problem with what happens when the
> ARM IRQ is finally enabled.  It appears that the system crashes
> if there is a pending interrupt when that happens.

Strange, that would mean you can't disable and reenable the IRQ without
problem...

-- 
Fabrice Gautier
fabrice_gautier@sdesigns.com 

Re: [ECOS] Initialization routines take too long?

[Grant Edwards]

On Fri, Nov 10, 2000 at 12:09:55PM -0800, Fabrice Gautier wrote:

> > > Why should your timer be initialized before everything it needs is
> > > initialized?
> > 
> > I'm not sure what you mean.  The timer doesn't need anything
> > else to be initialized before it is initialized.
> 
> I meant that maybe your timer IRQ handler used some classes (Counter, Alarm
> maybe...) which constructor had not been called before your handler is
> called.

My part of the IRQ handler doesn't use anything external -- it
just returns the highest pending vector ID by examining a CPU
register.  What eCos does with it I don't know.

I _think_ that IRQ is not enabled until after all of the
consctructors are called.  During my driver init() routines it
appears that individual interrupt sources have been unmasked
(enabled) but the global IRQ mask in the ARM CPSR is still set
(IRQ disabled). I'm currently sifting through the sources to
try to figure out where/when interrupts get enabled.

> Strange, that would mean you can't disable and reenable the IRQ without
> problem...

Don't know.

-- 
Grant Edwards
grante@visi.com

RE: [ECOS] Initialization routines take too long?

[Gary Thomas]

On 10-Nov-2000 Fabrice Gautier wrote:
>> -----Original Message-----
>> From: Grant Edwards [ mailto:grante@visi.com ]
>> Subject: Re: [ECOS] Initialization routines take too long?
>> 
>> 
>> On Fri, Nov 10, 2000 at 11:57:05AM -0800, Fabrice Gautier wrote:
>> 
>> > > It seems that if my first 10ms timer tick occurs before system
>> > > initialization is complete, something gets corrupted and the
>> > > system crashes in various different ways.
>> > 
>> > Why should your timer be initialized before everything it needs is
>> > initialized?
>> 
>> I'm not sure what you mean.  The timer doesn't need anything
>> else to be initialized before it is initialized.
> 
> I meant that maybe your timer IRQ handler used some classes (Counter, Alarm
> maybe...) which constructor had not been called before your handler is
> called. 
>  
>> > Maybe it's a problem in the constructors priority order.
>> 
>> I think it's more likely a problem with what happens when the
>> ARM IRQ is finally enabled.  It appears that the system crashes
>> if there is a pending interrupt when that happens.
> 
> Strange, that would mean you can't disable and reenable the IRQ without
> problem...

As far as I know, this is not a problem with any of our internal ports.
This is not to say that a problem does not exist, but we've never seen such.

However, note that the normal case is for interrupts to remain disabled,
sometimes for long periods, until the scheduler is started from the main
thread.  Is this how your application works [Grant]?

Re: [ECOS] Initialization routines take too long?

[Grant Edwards]

On Fri, Nov 10, 2000 at 01:19:25PM -0700, Gary Thomas wrote:

> >> I think it's more likely a problem with what happens when the
> >> ARM IRQ is finally enabled.  It appears that the system crashes
> >> if there is a pending interrupt when that happens.
> > 
> > Strange, that would mean you can't disable and reenable the IRQ without
> > problem...
> 
> As far as I know, this is not a problem with any of our internal ports.

I thought probably not.  ;)

> This is not to say that a problem does not exist, but we've never seen such.
> 
> However, note that the normal case is for interrupts to remain disabled,
> sometimes for long periods, until the scheduler is started from the main
> thread.  Is this how your application works [Grant]?

That depends on the meaning of "interrupts remain disabled".

The IRQ mask bit in the ARM CPU register CPSR remains set (IRQ
disabled) until Cyg_Scheduler::start() is called.  

However, individual interrupts are unmasked (enabled in the
interrupt controller) during initialization.  This means that
there may be an IRQ pending when Cyg_Scheduler::start() is
called.

If that is the case, the first IRQ is serviced before 
HAL_THREAD_LOAD_CONTEXT( &next->stack_ptr ) is called at the
bottom of Cyg_Scheduler::start().

I don't know enough about eCos internals to determine if that's
a problem or not.  

The only thing I can think of is that current_thread is set to
a value inconsistent with the actual CPU context at that point,
and that's causing a problem somewhere in the timer interrupt
code.

All of my tasks do seem to get started, but things crash in
random ways.  If I speed up my init routines (doesn't matter
which one) or delay that first timer interrupt, things are
fine.

-- 
Grant Edwards
grante@visi.com

Re: [ECOS] Initialization routines take too long?

[Grant Edwards]

> It seems that if my first 10ms timer tick occurs before system
> initialization is complete, something gets corrupted and the
> system crashes in various different ways.  I can make the
> problem go away by either printing less diagnostic stuff
> (that's where most of the time goes) in my init routines, or by
> changing the 10ms tick to a larger value.

After some additional testing I've managed to generate one of
the failure modes with a long timer period (no timer interrupt
pending when the scheduler starts).  So it appears not to be
the timer interrupt causing the problem.  There are two other
interrupts pending when the scheduler starts, so it may be one
of those...

-- 
Grant Edwards
grante@visi.com

Re: [ECOS] Initialization routines take too long?

[Grant Edwards]

On Fri, Nov 10, 2000 at 11:57:05AM -0800, Fabrice Gautier wrote:

> > It seems that if my first 10ms timer tick occurs before system
> > initialization is complete, something gets corrupted and the
> > system crashes in various different ways.
> 
> Why should your timer be initialized before everything it needs is
> initialized?

I'm not sure what you mean.  The timer doesn't need anything
else to be initialized before it is initialized.

> Maybe it's a problem in the constructors priority order.

I think it's more likely a problem with what happens when the
ARM IRQ is finally enabled.  It appears that the system crashes
if there is a pending interrupt when that happens.

-- 
Grant Edwards
grante@visi.com

RE: [ECOS] Initialization routines take too long?

[Fabrice Gautier]

> -----Original Message-----
> From: Grant Edwards [ mailto:grante@visi.com ]
> Subject: [ECOS] Initialization routines take too long?
> 
> It seems that if my first 10ms timer tick occurs before system
> initialization is complete, something gets corrupted and the
> system crashes in various different ways.

Why should your timer be initialized before everything it needs is
initialized?

Maybe it's a problem in the constructors priority order.

-- 
Fabrice Gautier
fabrice_gautier@sdesigns.com 

[ECOS] Initialization routines take too long?

[Grant Edwards]

I've discovered that if my driver initialization routines take
too long, my system chokes and dies.  At first I though it was
specific changes to drivers that were causing the problem.  But
after extensive gnashing of teath and rending of cloathes it
seems to be the total elapsed time that causes problems, rather
than any specific chunk of code.

It seems that if my first 10ms timer tick occurs before system
initialization is complete, something gets corrupted and the
system crashes in various different ways.  I can make the
problem go away by either printing less diagnostic stuff
(that's where most of the time goes) in my init routines, or by
changing the 10ms tick to a larger value.

Any suggestions on eliminating the requirement than init be
completed in 10ms?

-- 
Grant Edwards
grante@visi.com