NetBurner Community Forum

Posted: **Thu Aug 01, 2013 7:32 am**

Hello,

I'm getting a spurious interrupt/exception in my code very infrequently (unfortunately). In most of the posts I've read, this happens when the interrupt mask register is manipulated without changing the interrupt priority level in the status register. Can the same thing happen when the peripheral interrupt enable register is manipulated? For example, here are my interrupt enable and disable calls. The interrupt of interest is the external interrupt 3, which is set as a level-sensitive interrupt. Processors external to the NB module can pull this line low to request service:

Code: Select all


void EnableProcInterrupt (void)
{	// Enables the processor interrupt line (IRQ3) through the edge port registers of the Coldfire.  This allows the other processors to
	// interrupt the NB.

		USER_ENTER_CRITICAL();
			sim.eport.epier |= IRQ_3_INTERRUPT_ENABLE_BIT;	//IRQ3 active.
		USER_EXIT_CRITICAL();
		iprintf ("\n *************** Proc interrupt ENABLED.");	// NEXT: DEBUG

}

void DisableProcInterrupt (void)
{	// Prevents the processor interrupt from occurring.
	USER_ENTER_CRITICAL();
		sim.eport.epier &= ~IRQ_3_INTERRUPT_ENABLE_BIT;	//IRQ3 inactive.
	USER_EXIT_CRITICAL();

	iprintf ("\n *************** Proc interrupt DISABLED.");	// NEXT: DEBUG
}

Do I need to, or may I manipulate the sim.eport.epier register within the ISR, or might that cause this same issue?

Here is a dump from the latest trap. The faulted PC seems bogus (IE: points to code not in the meter update task, which is the one running):

-------------------Trap information-----------------------------
Exception Frame/A7 =0211B66C
Trap Vector =???? (Hex):0x18
Format =04
Status register SR =2000
Fault Status =00
Faulted PC =0203DBAE

-------------------Register information-------------------------
A0=021196CA A1=021196AA A2=8000E276 A3=8000E256
A4=02067A3C A5=000000A5 A6=0211B688 A7=0211B66C
D0=00000236 D1=00000800 D2=0000FFFF D3=00000003
D4=00000001 D5=000000D5 D6=000000D6 D7=000000D7
SR=2000 PC=0203DBAE
-------------------RTOS information-----------------------------
The OSTCBCur current task control block = 2000074C
This looks like a valid TCB
The current running task is: Meter Update#34
-------------------Task information-----------------------------
Task | State |Wait| Call Stack
Idle#3F|Ready | |02067AE4,02065EE8,0
Main#36|Ready | |02038E60,02034284,02065EE8,0
TCPD#28|Semaphore |0E42|02067746,02076228,02065EE8,0
IP#27|Fifo |007F|02066C24,0206AA70,02065EE8,0
Enet#26|Fifo |0039|02066C24,0207BD1A,02065EE8,0
Loud Calc#32|Mailbox |0000|0206743A,0203FFD2,02065EE8,0
Front Panel#31|Timer |000B|02067ACA,02028CCE,02065EE8,0
Grpx Dispatch#33|Fifo |0000|02066C24,02026A7C,02065EE8,0
Dolby Update#35|Timer |000F|02067ACA,020492BE,02065EE8,0
Meter Update#34|Running | |0203DBAE,0203DC24,02065EE8,0
Serial Mdata Parse#30|Semaphore |0000|02067746,02045822,02065EE8,0
Watch Dog#01|Timer |0020|02067ACA,0200368E,02065EE8,0

-------------------End of Trap Diagnostics----------------------

Thanks for the help.

Brian

Posted: **Thu Aug 01, 2013 7:30 pm**

As long as your interrupt routine is declared as:

Code: Select all

INTERRUPT( IRQ3_ISR, 0x2700 )

the '2700' is loaded into the SR before executing your ISR, and this disables any other interrupt for the duration of IRQ3_ISR, so you should be OK to modify epier inside IRQ3_ISR.

Posted: **Mon Aug 12, 2013 6:49 pm**

Great! Thanks for the information.

Brian

Posted: **Mon Aug 12, 2013 8:01 pm**

You are using level sensitive interrupts. Is there any possibility that the IRQs are causing a stack overflow because they re-trigger many times because the level (possibly only occasionally) remains active after the ISR? What causes the level to go high (inactive) again, and when does this happen? Would an edge triggered IRQ better insure 1 jump to the ISR per request (edge)? Multiple devices can still share edge-triggered IRQs using an open collector connection. You might also consider using more than one of the epier IRQ inputs for different devices. Just a few thoughts...

Posted: **Tue Aug 13, 2013 8:51 am**

I agree with RidgeGlider. My first suspect would be that the interrupt is not being cleared in the peripheral, and the ISR is getting called so many times it causes a stack overflow. That would make sense in that the trap is just out in the weeds somewhere. Why use level sensitive? Do you have multiple devices on the same IRQ signal?

NetBurner Community Forum

Spurious Interrupt In MOD5270

Spurious Interrupt In MOD5270

Re: Spurious Interrupt In MOD5270

Re: Spurious Interrupt In MOD5270

Re: Spurious Interrupt In MOD5270

Re: Spurious Interrupt In MOD5270