Problems with starting new BSP

Radzislaw Galler rgaller at
Wed Jul 4 06:30:28 UTC 2001

----- Original Message -----
From: "Joel Sherrill" <joel.sherrill at>
To: "Radzislaw Galler" <rgaller at>
Cc: <rtems-users at>; <jmills at>
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
> > the application is able to start all tasks and switch context to every
> > but only once. After that all tasks become waiting on timeout.
> This makes perfect sense.  Without a clock tick, you are not able to

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
> > infinite loop somewhere. If I leave interrupts enabled the system hangs
> > 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

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.



More information about the users mailing list