Hello All, I’m using the V4.2.0 ARM7_LPC2000 port of the FreeRTOS and have a almost working system with 5 tasks (including the Idle task) using cooperative task switching.  My problem is I consistently get an undef irq occurring which resets the system.  If I break the system at the point the undef handler is executed the call stack is only one function deep.  The position it seems to have jumped from to the undef handler is consistent but not meaningful. (Possibly looks like the stack has been corrupted?)  This position in the code normally executes fine and is very simple. I’ve looked for stack overflows for the tasks and cannot seem to see any.  I’ve also tried to reduce my use of pointers to the bare minimum and the ones I must use I’ve checked over very carefully.  Does anyone have any ideas to what this bug might be? Thanks in advance. Nick

Nick, Make sure your minimal stack size and heap are set correctly – meaning those are not being exhausted – and also – check to see if an IRQ has been enabled that does not have an IRQ handler installed. I have written some code – not for your part – sorry – I call ‘interrupt_grabber.c’ for this very purpose – it is helpful during bring-up of suspect boards – if an IRQ goes off that ‘shouldn’t’ – the respective simplistic handler will just spin – so it is easy to identify the source of the IRQ in the debugger.  On a lot of processors – if an IRQ goes off that doesn’t have a handler – it usually hits the reset vector.  Not sure if that is your problem but you may want to bang out your own interrupt_grabber.c just in case. HTH, John

The IRQ link register will hold the return address, not the stack, but I’m not sure that is helpful. You need to determine which IRQ is executing.

I have had some success by changing the compilation of the functions the undefined IRQ seemed to have jumped from to ARM code (previously the files the function were in were compiled as Thumb).  Although I haven’t been able to find an explanation as to why this helps.  The undef IRQ is called when a unknown instruction is attempted to be executed by the CPU.  I’m aware that the IRQ handlers must be compiled in ARM and I understand the the CPU can switch back and forth between ARM and Thumb modes relatively easily so I’m unsure why this would help.  Can anyone shed any light on this?

Cheers John and Dave for your suggestions.  John the interrupt is a specific one for ARM, the undef IRQ happens when a instruction not recognised by the CPU or it’s coprocessor(s) is attempted to be executed.  Dave you are right, the IRQ link register (R14_undef) contained the return address which was the same as the stack view.   This is what I was seeing as ‘the functions the undefined IRQ had seemed to jump from’.  Thanks for both your help.

Cheers John and Dave for your suggestions.  John the interrupt is a specific one for ARM, the undef IRQ happens when a instruction not recognised by the CPU or it’s coprocessor(s) is attempted to be executed.  Dave you are right, the IRQ link register (R14_undef) contained the return address which was the same as the stack view.   This is what I was seeing as ‘the functions the undefined IRQ had seemed to jump from’.  Thanks for both your help.