Problems with starting new BSP

Radzislaw Galler rgaller at et.put.poznan.pl
Wed Jul 4 06:30:28 UTC 2001


----- Original Message -----
From: "Joel Sherrill" <joel.sherrill at oarcorp.com>
To: "Radzislaw Galler" <rgaller at et.put.poznan.pl>
Cc: <rtems-users at oarcorp.com>; <jmills at tga.com>
Sent: Tuesday, July 03, 2001 3:11 PM
Subject: Re: Problems with starting new BSP


>
>
> Radzislaw Galler wrote:
> >
> > investigation I found out that disabling clock driver would help for a
while:
> > the application is able to start all tasks and switch context to every
one...
> > but only once. After that all tasks become waiting on timeout.
>
> This makes perfect sense.  Without a clock tick, you are not able to
timeout.

Does it make sense also for idle task? So is the clock driver necessary for
all multitasking applications?

>
> > Also if I enable clock driver and disable interrupts soon enough I am
able to
> > see some debugging info on terminal. But reenabling interrupts casues
some
> > infinite loop somewhere. If I leave interrupts enabled the system hangs
after
> > printing first three letters on terminal.
>
> When you say "reenabling interrupts", do you mean all potential interrupt
> sources?  My gut instinct says that you have an uninitialized interrupt
> source that is happening.  Do you have a spurious interrupt handler in
> your BSP to report an unexpected interrupt?

I do only
_CPU_ISR_Enable(level);

The rest comes from BSP (mostly from gensh2)

>
> I don't know if there is a generic sh spurious interrupt handler like
> there is for some other CPUs.  I think the m68k has a nice example of
> one.
>

Yes, there is but it does nothing but return. I'll try to handle it.

>
> If I am misreading things, it could simply be that the clock tick
> occurs once and is never cleared or setup properly to fire again.
>

Then it wouldn't work also on EVB, or would it? I didn't change the
interrupt handling routine.

Regards

Radek




More information about the users mailing list