Problems with starting new BSP

[Ralf Corsepius]

Radzislaw Galler wrote:
> 
> On Tuesday 03 July 2001 12:11, Joel Sherrill wrote:
> > 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 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.
The gensh*-interrupt handling works a little different from what is
used for other CPUs.

We assume a preset vector-table in ROM to copied into RAM at startup
and another vector table (RTEMS's vector table) to be merged into
this.


> After I twiddled a bit with interrupts trying to catch the spurious ones the
> system started to work, but I don't know what helped, because when I tried to
> get back to the previous state (using old files) the system also worked.
> 
> It could be that I lost couple of days seeking a nonexistent bug which only
> needed to touch sources and recompile the libraries  :)
> 
> Anyway right now I'm quite suspicious about #pragma interrupt directive
> (although it works now).
What do you mean? Does #pragma interrupt work or does your
application works?

For a very long time #pragma interrupt was broken for the sh (cf.
isp7032.h), and AFAIK still is (If having more than 1 #pragma
interrupt inside a source-file only the first ISR was treated as an
ISR, all subsequent ones were treated as functions=.

However, IIRC, since gcc-2.95.2 __attribute__(( interrupt ))
(syntax?) is reported to work.

Ralf