Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem TCP & FAT




Loading

Problem with undef irq

Posted by Nick Ward on July 10, 2009
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

RE: Problem with undef irq

Posted by John W. on July 10, 2009
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

RE: Problem with undef irq

Posted by Dave on July 10, 2009
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.

RE: Problem with undef irq

Posted by Nick Ward on July 14, 2009
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?

RE: Problem with undef irq

Posted by Nick Ward on July 14, 2009
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.

RE: Problem with undef irq

Posted by Nick Ward on July 15, 2009
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.


[ Back to the top ]    [ About FreeRTOS ]    [ Sitemap ]    [ ]




Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.

Latest News

FreeRTOS kernel V10 is available for immediate download. Now MIT licensed.


FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

IAR Partner

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

STMicro RTOS partner supporting ARM7, ARM Cortex-M3, ARM Cortex-M4 and ARM Cortex-M0

Texas Instruments MCU Developer Network RTOS partner for ARM and MSP430 microcontrollers

OpenRTOS and SafeRTOS