View topic - QNX Lockup after Interrupt

QNX Lockup after Interrupt

General Help about QNX

QNX Lockup after Interrupt

Postby kloll » Wed Feb 03, 2010 3:51 pm

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.
Attachments
Stripped Interrupt class.zip
Interrupt setup and processing
(2.29 KiB) Downloaded 206 times
kloll
Active Member
 
Posts: 10
Joined: Wed Feb 03, 2010 3:27 pm

RE: QNX Lockup after Interrupt

Postby mario » Wed Feb 03, 2010 6:14 pm

Maybe you should reset (ResetInterupt) the device before unmasking it.
mario
QNX Master
 
Posts: 4132
Joined: Sun Sep 01, 2002 1:04 am

Postby Tim » Wed Feb 03, 2010 6:14 pm

Kloll,

Looking briefly at the heart of your code:

Code: Select all
   //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
Tim
Senior Member
 
Posts: 1511
Joined: Wed Mar 10, 2004 12:28 am

Postby kloll » Wed Feb 03, 2010 7:25 pm

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.
kloll
Active Member
 
Posts: 10
Joined: Wed Feb 03, 2010 3:27 pm

Postby kloll » Wed Feb 03, 2010 7:30 pm

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
kloll
Active Member
 
Posts: 10
Joined: Wed Feb 03, 2010 3:27 pm

Postby mario » Wed Feb 03, 2010 10:17 pm

Are you sure the interrupt number returned by Get_IRQ_Number is the right one?
mario
QNX Master
 
Posts: 4132
Joined: Sun Sep 01, 2002 1:04 am

Postby kloll » Thu Feb 04, 2010 2:11 pm

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?
kloll
Active Member
 
Posts: 10
Joined: Wed Feb 03, 2010 3:27 pm

Postby Tim » Thu Feb 04, 2010 3:37 pm

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
Tim
Senior Member
 
Posts: 1511
Joined: Wed Mar 10, 2004 12:28 am

Postby kloll » Thu Feb 04, 2010 3:53 pm

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.
kloll
Active Member
 
Posts: 10
Joined: Wed Feb 03, 2010 3:27 pm

Postby mario » Thu Feb 04, 2010 4:23 pm

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.
mario
QNX Master
 
Posts: 4132
Joined: Sun Sep 01, 2002 1:04 am

Postby kloll » Thu Feb 04, 2010 10:07 pm

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.
kloll
Active Member
 
Posts: 10
Joined: Wed Feb 03, 2010 3:27 pm

Postby mario » Thu Feb 04, 2010 10:15 pm

kloll wrote: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.


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.
mario
QNX Master
 
Posts: 4132
Joined: Sun Sep 01, 2002 1:04 am

Postby Tim » Fri Feb 05, 2010 2:05 pm

Mario,

Kloll stated earlier that:

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.


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
Tim
Senior Member
 
Posts: 1511
Joined: Wed Mar 10, 2004 12:28 am

Postby kloll » Fri Feb 05, 2010 2:34 pm

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?
kloll
Active Member
 
Posts: 10
Joined: Wed Feb 03, 2010 3:27 pm

Postby Tim » Fri Feb 05, 2010 3:27 pm

Kloll,

kloll wrote: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.


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.
Tim
Senior Member
 
Posts: 1511
Joined: Wed Mar 10, 2004 12:28 am

Next

Return to Help

Who is online

Users browsing this forum: No registered users and 2 guests