vxWorks "Exception at interrupt level" problem
paolo
We are using vxWorks 5.5; our application crashes and issues on
consolle the following message:
Exception at interrupt level
Condition reg 0x80000082
Fp Control and Status Reg 0x38F750
Regs at 0xb626b8
and then the system reboots
does anyone has any suggestion to detect the reason of this
Exception ?
thank you
nois...@gmail.com
No, because you have not told us enough information:
- You didn't tell us what CPU you're using
- You didn't tell us what kind of board you're using (eval board? your
own custom hardware?)
- You didn't tell us what device drivers you're using (ones that come
with VxWorks? ones you wrote?)
- You didn't tell us the nature of your application or what it does
-Bill
paolo
>
> - Mostra testo citato -
sorry, some more details:
Our CPU is an IBM powerPc 750, we are using a Curtiss Wright SCP122
board,
we wrote some of the drivers (to control an external board via PCI
Bus) and
use also some of the board BSP drivers. Out application controls
various external
equipments using serial lines and ethernet bus. The UART and Ethernet
chip reside on the external board.
thank you,
Paolo
nois...@gmail.com
Well, "Exception at interrupt level" literally means what it says:
there was a runtime fault in interrupt context (as opposed to task
context). One thing that's not clear is what do you have to do to
provoke the crash (does it crash immediately on boot? does it only
fail under load?).
It could point to a bug in one of the interrupt service routines
you've written for one of your own drivers. (It could be in another
driver too.) A lot depends on just what your ISR routines do. There
are a couple of things that I can think of which might lead to this
crash:
- Accessing an invalid PCI I/O register in the ISR
- Dereferencing an invalid data pointer in the ISR code (i.e. touching
an unmapped address)
- Branching to an invalid address within the ISR (bad function
pointer)
- A transient PCI bus error of some kind causing an otherwise valid
PCI register access to trigger an abort or trap
- An interrupt firing for a device for which no ISR has been installed
- Memory corruption causing the ISR vector/handle table to be corrupt,
leading to a valid ISR to be invoked
with a bad context handle (or causing the interrupt handler code to
branch to a bogus address)
If you can actually dump the saved register info (at the address shown
by the "Regs at" line in the exception output), it may give you a clue
as to what code was executing which caused the exception. If not, you
may need to use the hardware debug tools (Wind River ICE or Probe),
since that will let you stop the CPU right when the exception occurs
and examine the CPU state and memory. Unfortunately I don't think this
is the sort of thing you can debug using the Workbench debugger since
that requires communication with the WDB agent task running on the
target (and this kind of exception is fatal to the whole OS, including
the WDB task).
If you don't have an ICE or probe, check to see if the board has a
debug display of some kind (preferably alphanumeric LED or LCD). If
so, you can try instrumenting the ISRs so that they output something
to the display so that you can determine which one was running at the
time of the crash. (The alternative, putting debug logMsg()s in your
ISRs, will slow down the system and since logMsg() depends on
tLogTask, you have the same problem as with the WDB agent task.)
-Bill
paolo
Hi,
we solved the problem. Looking at register's dump we found into lr
an address corresponding to one of ours interrupt routines. Some
protective code was missing in it and it caused a wrong function
call which caused a jump to wrong memory location. We added a check
a now it works properly.
Thank you for useful suggestions.
Paolo