auto interrupt 7

auto interrupt 7

Post by ttt » Wed, 07 Nov 2001 10:58:54



Dear all,

Any idea why I'm getting "auto interrupt 7" error all the time when I'm
running my program?

Thanks
T.L.

 
 
 

auto interrupt 7

Post by Ben Combe » Wed, 07 Nov 2001 12:04:30



> Dear all,

> Any idea why I'm getting "auto interrupt 7" error all the time when
I'm
> running my program?

Is this in POSE?  Where are you seeing this message?  I've never heard
of "auto interrupt 7" before, especially with regards to Palm OS
programming.

 
 
 

1. VME interrupts interrupting VME interrupts

This question has to do with a higher priority VME interrupt interrupting a
lower priority one. Preempting here means that if a lower priority ISR
(interrupt service routine) is running, the higher priority one will "interrupt"
it, finish its ISR, and then the lower priority interrupt's ISR will continue.

We are VxWorks "users", not "developers". Or, our application is a laboratory
engine control and instrumentation system that is VME and VXI with all hand
written C; we are not writing BSPs. However, we are not totally ignorant; we do
know a bit about VxWorks and its inner workings. Also, the main motivation
behind all this is that we have one interrupt for which we would like to keep
the latency "constant", which is the case on a 68k board. We are trying to get
this to work on a PPC board, on which the interrupt latency happens to not be
"constant".

We are using VxWorks 5.3.1 (and 5.2 and even 5.1), but not really using Tornado
1.?, since we use "5.2 mode" with the shell on the target and a startup script
or whatever it's called; we do it the old fashioned way.

The VME specification prioritizes the IRQ levels (and then the daisy chain
prioritizes interrupters on the same level), and says that if two interrupts
occur simultaneously, the higher priority one will be serviced first. I haven't
found any spec. for what should happen if a higher priority interrupt is
asserted while a lower priority interrupt's ISR is executing.

The context of the question is the situation on a 68k board versus a PPC (604)
board that uses a Universe II VME-PCI interface. On the 68K board a higher
priority interrupt does preempt a lower priority one (as observed using some
hardware signals), while on the particular PPC board, if the lower priority
interrupt is running while the higher priority one is asserted, the higher
priority one does not execute until the lower priority ISR has completed.

We understand the concept of why this is so; the 68k interrupts _are_
prioritized, while on the PPC BSP the Universe II uses one PCI interrupt for all
VME interrupts. Some people have said that one might be able to remap one or
more of the VME interrupts to another PCI interrupt. We can see how this might
happen (we have the Universe II user manual, among other info).

Without enough detailed knowledge, it is hard to tell how difficult remapping an
interrupt would be, and if one would even want to do it (i.e., modify the BSP
for one particular situation).

So, the question more or less is if anyone has any similar experience with, or
comments on this situation. What I would really like to know is if anyone knows
if we have any hope of readily doing this, or if it would get really ugly. I
don't wish to spend a lot of (or, rather, more)  time on this. The vendor is
already (apparently) pondering the question as well. Thanks for any assistance
or comments.

--
Francis Connolly            Technical Specialist
FMC-FAO-PD-R&VT-P&AE-CAPE-APPTE-CEFET-P/T ET

313-317-7404 fax                CDS ID: fconnoll

2. Is it possible to have a sort of Global Cookie.

3. 1.Visor: auto interrupt 7

4. How to Print from SUNSparc II ??

5. Visor: auto interrupt 7

6. vbrun300.dll

7. VueScan, lock exposure, auto whitepoint, auto blackpoint

8. ActiveX IS NO match f

9. Differences between Auto-Sensing and Auto-Negotiation in Ethernet

10. convert non-auto increment to auto-increment?

11. removing 'auto-level' from auto pilot...

12. Auto Pilot Auto Land

13. debuging fads860 interrupt problems "uninitialized interrupt"