CODEWITHSUNDEEP
driverinterruptinterrupt-handlingpowerpcvxworks
capt tuttle
capt tuttle

Reputation: 1

interrupt handler not executing on the interrupt it was install for

I am converting a vxWorks 6.9 BSP/drivers to vxWorks 7. This is a SPI a/d driver for the MPC82xx PPC. In the attach function I call the vxbIntConnect function and pass it then name of my ISR 'adc_isr'. I am using a Lauterbach JTAG debugger to attempt to isolate the issue.

After boot, on the console I run intShow() and my installed adc_isr() is shown as expected.

In the adc_write, as soon as I set the 'transmit now' bit, the JTAG debugger shows the expected values in the SPIE register (transmitted, received, rx interrupt) and the SIU registers also show interrupt pending, and the SPI int is enabled.

Prior to executing the adc_write, I set a hw breakpoint in the adc_isr. The SPI write is in a intLock/intUnlock block. As soon as I try to step over the intUnlock(), the code does NOT execute the adc_isr() {the breakpoint never occurs}, instead an exception is generated, and it tries to run the detach() routine for the SPI--but it can't complete that and goes into an infinite loop in the intLib.c code. The ISR has code to clear the int, but since it is not executing, I believe that what executes is causing a interrupt stack overflow or other catastrophic error.

I gave up trying to trace further execution at that point. I should point out that the vxWorks 6.9 code executes properly. The vxWorks 7 vxbIntConnect and vxbIntEnable calls, in attach, from all indications are properly connecting the ISR (ie the HW int is happening, no errors are returned on those calls, and the intShow displays the expected ISR handler for the int (2). I have tried changing the DTS to change the interrupt from low-level, to falling-edge--but this did not fix anything. One delta between the 6.9 and 7.0 code is that the 6.9 sets the int level to 63. I have been unable to find out how to do this in vxWorks 7.0. Although I am hard pressed to believe that a priority issue could cause a handler to not be vectored to properly.

Does anyone have any idea on possible cause(s)? or how to further troubleshoot the issue?

Upvotes: 0

Views: 1042

Answers (1)

Benoit
Benoit

Reputation: 39094

This sound like the interrupts are not mapped correctly in your configuration file.

When it comes to interrupts, VxWorks 7 uses a Device Tree structure (.dts) in the BSP directory which contains the hardware description. One of the key thing is that the entry for your ADC hardware should specify the correct interrupt.

In VxWorks 6.9, this instead was configured via a series of data tables located in the hwconf.c file in the BSP directory. Make sure that whatever interrupt was specified in the 6.9 hwconf.c file for your device is the same as specified in the dts file.

Upvotes: 0

Related Questions