topic Re: MCF52233 DEMO Interrupt Priorities and Levels in ColdFire/68K Microcontrollers and Processors

MCF52233 DEMO Interrupt Priorities and Levels

jes — Wed, 16 May 2007 20:34:04 GMT

Hi,

I've been working with the DEMO board for a bit now and I've noticed that the code has assigned the same Interrupt Priority and Level to a number of interrupts. This is expressly forbidden according to documentation, see below. I only discovered this after indeed seeing some undefined behaviour with respect to interrupts. This seems like a very elementary mistake as we came across this problem previously for a 5213 ColdFire. Providing unique and non-overlapping level and priority definitions avoided the undefined behaviour in 5213 and I'm hoping same is true of 52233. Has anyone else caught this error?

15.3.6 Interrupt Control Register (ICRnx)

Each ICRnx, where x equals 1, 2,..., 63, specifies the interrupt level (1–7) and the priority within the level

(0–7). All ICRnx registers can be read, but only ICRn8 to ICRn63 can be written. It is the responsibility

of the software to program the ICRnx registers with unique and non-overlapping level and priority

definitions. Failure to program the ICRnx registers in this manner can result in undefined behavior. If a

specific interrupt request is completely unused, the ICRnx value can remain in its reset (and disabled) state

Re: MCF52233 DEMO Interrupt Priorities and Levels

soccermike — Wed, 23 May 2007 00:10:55 GMT

I'm using the 52223 Coldfire EVB and 52221 Demo boards. I've noticed that none of the examples I saw used interrupts. Everything including the USB is polled. I does make bringing up a new system that much more challanging for the first timer. I've been able to create interrupts for the PIT.

Re: MCF52233 DEMO Interrupt Priorities and Levels

jes — Wed, 23 May 2007 01:46:38 GMT

The FEC uses interrupts and the UART makes accommodations for them but the DEMO defaults to POLLED_UART via a #define. The PIT Timer is also being used. eg. FEC_Init() assigned Priority and Level to 6 for vectors 23 - 36 (ie 0x30 in ICR23-ICR36 registers). Check out - View -> Registers and take a look at ICRx assigned priorities and levels after reset. You'll find many share value 0x18 and 0x30. Why it works at all without generating exceptions with this many non-unique vector priorities/levels is a mystery. I modified the vectors to have unique priorities and levels.

I'm still having a bit of trouble with UART interrupts anyway. I modified code to be UART interrupt driven and it works - for the most part. The one remaining problem is an "Illegal Instruction" exception that is generated at reset when I use the DHCP_CLIENT (with some mods) and demo code is spitting out start-up messages via the printf statement. When I get the above exception I can alter the PC to the RTE instruction and do a return from the exception. But the instruction that it returns to is certainly not an illegal instruction. I suspect this 'Undefined behavior' may have something to do with a conflicting interrupt somewhere as I've seen similarly behavior before in the 5213. Or perhaps I'm missing something more obvious.

I'd have to say I'm not too pleased with the quality of the DEMO code. Too many 'fixes' and other mods look to have been made to push the demo out the door. Flip what you would think is a simple alternative implementation via a #define and you have to fight your way thru the code to see why it now doesn't work. UART is a good example of that. Other code commented out with no explanation and other places questionable crumbs look to have been left.

(Go AC Milan! No crash and burns like in Istanbul hopefully.)

Re: MCF52233 DEMO Interrupt Priorities and Levels

soccermike — Fri, 15 Jun 2007 01:52:38 GMT

Thanks for the encouraging and helpful words. We are making progress with many of the subsections. Turns out that we won't have to write much USB code. The example code did nearly everything we needed other than to make it interrupt driven instead of polled.

Do you have $50M to help AC Milan sign Henry, Drogba, Eto'o & Emerson. Who would sit on the bench?
They are going after any name that is standing!

Re: MCF52233 DEMO Interrupt Priorities and Levels

bkatt — Sat, 16 Jun 2007 03:42:45 GMT

I'd have to say I'm not too pleased with the quality of the DEMO code. Too many 'fixes' and other mods look to have been made to push the demo out the door. Flip what you would think is a simple alternative implementation via a #define and you have to fight your way thru the code to see why it now doesn't work. UART is a good example of that. Other code commented out with no explanation and other places questionable crumbs look to have been left.

I agree. I call it "EMG considered harmful". The UART code included some support for different logical numbers vs. physical uart numbers, but that was broken when I tried to use it. The heap allocation stuff works but the statistics and debugging code with it is broken. There's a nasty bug in printf where they expand LF to CRLF in some cases but not in others; this will screw you up if you are using sprintf to build a multi-line web response where you need just 1 CR before the LF. I ended up discarding the entire EMG webserver and built a complete replacement.

We see some strange things happening with the ethernet code that are still unresolved. I noticed that they used identical vectors and priorities, but I didn't see an easy way to change it so I haven't fixed that yet.

There's an assembly language ISR (asm_exception_handler) that does not save D2, then calls into C code. Apparently CodeWarrior/Coldfire treats D2 as scratch like D0-D1 and A0-A1, while D2 is preserved by subroutine calls in GNU compiles.