Quality RTOS & Embedded Software

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




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) 2004-2010 Richard Barry. Copyright (C) 2010-2016 Real Time Engineers Ltd.
Any and all data, files, source code, html content and documentation included in the FreeRTOSTM distribution or available on this site are the exclusive property of Real Time Engineers Ltd.. See the files license.txt (included in the distribution) and this copyright notice for more information. FreeRTOSTM and FreeRTOS.orgTM are trade marks of Real Time Engineers Ltd.

Latest News:

FreeRTOS V9.0.0 is now available for download.


Free TCP/IP and file system demos for the RTOS


Sponsored Links

⇓ Now With No Code Size Limit! ⇓
⇑ Free Download Without Registering ⇑


FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

Renesas Electronics Gold Alliance RTOS Partner.jpg

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

Atmel RTOS partner supporting ARM Cortex-M3 and AVR32 microcontrollers

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

Xilinx Microblaze and Zynq partner

Silicon Labs low power RTOS partner

Altera RTOS partner for Nios II and Cortex-A9 SoC

Freescale Alliance RTOS Member supporting ARM and ColdFire microcontrollers

Infineon ARM Cortex-M microcontrollers

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

Cypress RTOS partner supporting ARM Cortex-M3

Fujitsu RTOS partner supporting ARM Cortex-M3 and FM3

Microsemi (previously Actel) RTOS partner supporting ARM Cortex-M3

Atollic Partner

IAR Partner

Keil ARM Partner

Embedded Artists