QNX Lockup after Interrupt

GENERAL Help
1

System
QNX 6.3.2
CPU card Winsystem PPM-LX800-G (pc104plus x86)
Excalibur EXC-4000P104Plus card with M4K1553-PCS configured as RT (PCI card)

I am trying create a thread attached to the 1553 cards Interrupt.

When I send a message to the 1553 card QNX hangs. The 1553 card responds(it is an intelligent card) with valid data.

I have tested the 1553 code as a polled device and this works.
PCI PinID of 1553 is A with interrupt 10. When I use the PCI -vvv command there are other PCI devices with PinID of A but they have Interrupts of 11.

The code I am using was copied from a non PCI interrupt routine.

below is a snippet of how I am attaching the interrupt.

// enable I/O privilege
status = ThreadCtl(_NTO_TCTL_IO, NULL);
if(status == -1)
{
cout << "ThreadCtl, _NTO_TCTL_IO error: errno = " << errno << ": " << strerror(errno) << std::endl;
}

// Setup the 1553 board for RT interrupts
SetupRTInterrupts();

// Set Responce Mode RT Active
m_p1553RtBoard->SetResponseMode(M4KRTClass::VALID_RESPONSE_NOT_BUSY);

// initialize hardware
SIGEV_INTR_INIT(&IsrSigEvent);
m_p1553RtBoard->Get_IRQ_Number(&m_Interrupt);
m_IrqId = InterruptAttachEvent(m_Interrupt,
&IsrSigEvent,
_NTO_INTR_FLAGS_TRK_MSK);

Any ideas as to why the sytem hangs… I can not even terminate the threads via Momentics.

Thanks in advance for any help.

2

Maybe you should reset (ResetInterupt) the device before unmasking it.

3

Kloll,

Looking briefly at the heart of your code:

   //now service the hardware when the interrupt is detected
   while (1)
   {
      InterruptWait(0, NULL);
      IntCount = IntCount + 1;

     // Clear and process the interrupt
     if(m_p1553RtBoard->InterruptOccurred())  // check to see if this is from our module
      {
         InterruptUnmask(m_Interrupt, m_IrqId); // QNX function
         m_p1553RtBoard->ResetInterrupt();
      }

     //increment the notification semaphore
      m_p1553ChangeSemaphore->Put();

   }

What’s going on in this call:

m_p1553RtBoard->InterruptOccurred()

If that call doesn’t return true, you don’t unmask the interrupt. Are you sure that’s not happening when the system hang occurs?

Also what’s going on in here:

m_p1553RtBoard->ResetInterrupt();

I assume you are resetting the interrupt on the card itself?

What I would try to do if I were you is determine exactly where the hang is occurring. By that I mean using the debugger and stepping through the code (this is why you use interruptattachevent instead of interruptattach) or at least putting in print that say ‘I am here’.

Tim

4

I have a breakpoint after the InterruptWait call on the IntCount line. I have also tried a cout, but never get past the Interrupt wait.

The m_p1553RtBoard->InterruptOccurred() checks the carrier board interrupt status register, there can be up to 4 modules on the carrier. The m_p1553RtBoard->ResetInterrupt() resets the modules interrupt occured bit.

5

I also have another thread running to print IntCount in a loop and as soon as I send a message, from another system, to generate the interrupt the print stops. I have to restart both the QNX system and Momentics

6

Are you sure the interrupt number returned by Get_IRQ_Number is the right one?

7

It is the same as what is returned by the pci -vvv command for the card.

Most of the devices returned by the pci command are pin A and interrupt 11, except for the 1553 card it is pin A interrupt 10. I tried manaully setting the interrupt to 11 as a test but the InterruptAttachEvent call never returned when I did that.

Question: Could there be some option in QNX that I have not enabled?

8

Kloll,

Question: Could there be some option in QNX that I have not enabled?

Nope, there is so special option you need to set to receive interrupts other than what your code already does.

Where did you get the code for this routine that sets the board to interrupt mode?

SetupRTInterrupts();

Did it come from the board manufacturer? I wonder if there is something wrong in there as in some setting you missed.

Out of curiousity, can you change your code to simply set the board to interrupt mode and then exit (ie don’t attach/wait for interrupt). Then run your program to put the board in interrupt mode. Then send a message from another system to trigger the board with your program not running. Does QNX hang then?

Tim

9

SetUpInterrupt is mine based on Manufacturer code. it just has to set one register.

I have a main running that prints IntCount in a loop. When I run this code IntCount is printed until I send a message from my second machine. then it stops. By stop I mean I get no responce from Momentics and have to restart it. and the target. Everything looks normal until I send the message to generate the interrupt, that is why I am leaning toward it not being a 1553 board problem.

10

Typicaly if numlock key doesn’t work on the keyboard then it is because the machine is stuck in a ISR or is overloaded with ISR. If the numlock key works then it usually means a high priority thread is using all the CPU.

My gut feeling tells me you have an interrupt issue.

11

after the lockup no keyboard entry is seen.

My understanding is that QNX masks the interrupt so I would not get multiple prior to at least getting to my thread.

12

I’m not talking about keyboard entry I’m talking about the numlock key making the numlock led toggle.

Yes QNX will mask the interrupt, but if after unmasking it the interrupt line is still active ( PCI interrupt are level ), there will be interrupts back to back , for ever.

Also as I said ealier put the InterruptUnmask AFTER the reset of the interrupt line. Because after the interrupt is unmask the line is still active because it hasn’t been reseted yet.

13

Mario,

Kloll stated earlier that:

from which I took to mean that he never hit his breakpoint.

That would seem to indicate that that the progam is never getting a chance to reset the line or umask the interrupt. It also points again to your earlier comment about not having the right interrupt line.

Tim

14

Tim,
Your statement is correct about theflow, I never get past the InterruptWait.

I just tried using the InterruptAttach but no change.

I have also tried using 11 in the InterruptAttachEvent but the call does not return.
The CPU board mapping in BIOS of PCI is A-11, B-10, C-10, D-11. When I do a pci -vvv I get the card at pin A interrupt 10, this is also what is returned in the code by the pci inf structure returned by pci_attach_device.

I agree it is probably an interrupt mapping problem but I do not know any way to change it. I have tried playing with the BIOS settings.

I read in the PCI 104 plus documents that the Interrupt pin is shiffted 1 each layer of the stack i.e pin A goes into pin B on the second card in the stack, etc. Does this ring any bells?

15

Kloll,

Wait, does this mean the BIOS on your PC-104 card is set to do plug-n-pray? QNX doesn’t support plug-n-pray and the doc’s mention specifically to turn this off or else PCI mappings don’t work correctly.

If you have that turned on it could well be why the interrupt isn’t mapped correctly.

Tim

P.S. What Mario wrote about moving the interruptUnmask should definitely be done.

16

Thanks, I will check to see if Plug and Pray, as you put it is enabled. will post the results of check.

Any pointers as to where I can find information on this??
How is this different then the PCI_attach etc functions?

I am new to QNX and this system was set up by a person in our company that is out this week, so I am flailing a little.

BTW: I have moved the interruptUnmask as suggested.

17

Kloll,

The plug-n-play setting will be in the BIOS, not in QNX.

Tim

18
  1. The board does not support plug and Play.
  2. the board may have an PCI to ISA interrupt mapping issue. they are working on an issue with a USB board interrupting and hanging the board. Hopefully this will solve my problem.

I am getting a PCI_UNSUPPORTED_FUNCT when pci_map_irq is called during the initialization.

19

Kloll,

PCI and ISA can’t share interrupts. So yeah, this sounds like exactly your problem as the ISA would hang the board.

Tim

20

Just got in another SBC from a different manufactuer, Same problem.

Another point of reference is the 1553 card only interrupts on PCI A which I have mapped to interrupt 5. When I do a InterruptAttachEvent the code hangs at that point, NO return from the call.

If I change the interrupt number passed in the call returns but the system hangs when I generate the interrupt.

I have tested the basic functionality of the Interrupt routine with another I/O board and it does work.