Coldfire V2 Kernel ISR invoked even while it's masked

[philroth]

I have my own hardware design based off the MCF52259twr design and it's been working well for years. Recently added support for 2 RS232 ports with interrupt driven TX and RX.  Using UART0 and UART1. Running CW V 11 and MQX 420.

When I run a single port hard, meaning the ISR gets a TX event while servicing RX, everything works fine.

When I run both ports hard at the same time, meaning UART0 can be interrupted by UART1, things get a little bizzare. I'm sure it's not a stack problem, there are no globals being accessed. These are kernel_isrs created with _int_install_kernel_isr(MCF5225_INT_UART0, comm1_isr); and _int_install_kernel_isr(MCF5225_INT_UART1, comm2_isr), on IRQ 14 an 15

I am very familiar with working at this low layer and already have 4 kernel isrs for DTIMs running multiple stepper motors and sure they experience the same re-entracy aned nesting issues that the UARTs do and those run flawlessly.  It's just these silly UARTs giving me the problem.

What;s happening is somehow vector 15 (UART2) is getting activated.  I know this for a fact because MQX defaults all unused vectors to DEFAULT_ISR( ) and I was always getting to that so I looked into dispatch.c and saw it was being called by IRQ level 15 (UART2). Then I installed a kernel ISR for IRQ 15 just to be able to set a breakpoint and sure enough the breakpoint hit when the problem occurred.

When I hit the breakpoint, I looked at IMRL0 and IRQ15 wasn't even enabled, it was still masked.Looked at the INTFRCLO to see if the IRQ was somehow forced but again, that bit wasn't enabled.

So I'm kind of stumped why everything works fine, then all of a sudden the core vectors to the wrong ISR which is masked off

Any thoughts on this are appreciated

Best Regards

Phil Roth

[philroth]

Duplicate post.  Please delete

[TomE · Accepted solution]

There are three ways to make these bad things happen with interrupts:

1 - Use IPL7. So just don't. Ever. Unless you really need a non-maskable interrupt to fire ONCE.

2 - Interrupts with the same Level and Priority. You can't have duplicates as it confuses the interrupt controller.

3 - Leaving CPU interrupts enabled when you change the interrupt enables in the interrupt controller or anywhere else. Make sure you force the CPU to IPL7 around all of these, and that explains why (1) above is a bad idea too.

> These are kernel_isrs created with _int_install_kernel_isr(MCF5225_INT_UART0, comm1_isr);

Where are the priorities and levels specified? You didn't include enough for for use to see. Or are the "lower levels" meant to handle all of that for you? Maybe you need to check the source code for those function.

Tom

[philroth]

Tom,

I can't thank you enough.  It seems like moving each UART to a different level fixed the problem. I had them all set to not only the same level, but the same priority (3:6) as well as the 4 DTIM stepper motor ISRs which had Level:Priority  (2:6).  Now UART0 is 3:1, UART1 is 4:1.

I stress test this by some code that echoes COM1 to COM2 and COM2 to COM1 and connect both ports to a PC.  Then run Hyperterminal to send a 1MB file from each port simultaneously and capture the data coming back to a file, all while sending data coming into both ports out a TCP port which I again capture to a 3rd file on the PC. While this is happening I have 4 stepper motors executing random motion profiles to work test  the DTIM Isrs and make sure no steps are missing and the motors position perfectly. Max clock rate on the steppers are about 20 kHz.

It used to run for 2-3 mins sometimes, sometimes, 5 mins, but that was it. As I'm writing this, it's been running for 3 hrs and all motors are dead nuts and files created on the PC match perfectly.

Really hard to believe the same Level and Priority messed this up.I work from home and spent all last week and the weekend trying to figure this out

You gave me advice on the timers when I first designed this hardware which was much appreciated and have helped me out again here so Thanks again. I can send you the schematic and some code of the low level stuff which I'm pretty proud of if your interested.

Best Regards,

Phil Roth

NBS Card Technology Corp