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


V5.0.2 on AVR32 generates data exceptions

Posted by Jeff Henshaw on June 8, 2008
I was using FreeRTOS v4.7.2 as provided by Atmel. My code is derived from their FreeRTOS + LwIP demo. Today I merged in the changes between 5.0.2 and my code, including the needed change to macb.c that was provided with the 5.0.2 code. I merged files partly because I'd modified a couple of headers (moved timing info to a central header file) and partly so I could get a feel for where & how extensive the changes were. I'm pretty sure I merged things correctly, although there's always the chance of error.

I've deleted most of the examples from my code, leaving just vLEDFlashTask as a visual indicator that things are running. In the demo code, only the Basic web server is enabled, the tftp & smtp options are disabled.

I've implemented SDRAM, and re-done the linker script so that I can place globals and such in SDRAM when needed. Currently the heap (using heap3.c) is implemented in SDRAM, so all stacks & such are located in SDRAM. I haven't run into any problems with this, and so far nothing but the heap is in SDRAM. Heap size is 128k. I've set the default stack size to 4k.

My code still compiles, but throws a data exception error during runtime. All tasks are running at priority tskIDLE_PRIORITY + 1. I've added one small task called MeterTask, which is created last (6th task, idle task is 7th). configMAX_PRIORITIES is set to 16. The tasks are all created before the scheduler runs. Pre-emption is enabled.

When I call xTaskCreate() for my task, it calls prvAddTaskToReadyQueue() which calls vListInsertEnd(). This line then yields a data exception:

pxIndex->pxNext->pxPrevious = ( volatile xListItem * ) pxNewListItem;

Stepping the assembly and watching the registers doesn't show me any invalid data addresses, at least that I can tell - I'm pretty new to the AVR32 processor.

This is highly repeatable. However, if I change MeterTask's priority to tskIDLE_PRIORITY + 2, this no longer causes errors. However, when the scheduler starts, it then throws a different but related exception (bus error data fetch). I haven't yet run this one down to the exact source line.

Any thoughts?


RE: V5.0.2 on AVR32 generates data exceptions

Posted by Dave on June 8, 2008
Your task MeterTask is created before the scheduler starts, so it cannot be something in the context switch that is causing the problem.

Are there any interrupts firing that are attempting to unblock a task or cause a context switch before the scheduler has been started?

Are you using the same compiler version as before. I know there was some issue with the size of the code created when Atmel brought out a new compiler but this was some months back.

Have you updated all occurrences of xQueueGiveFromISR() to the new version where the last parameter is different? This was the major change in V5.0.0.

RE: V5.0.2 on AVR32 generates data exceptions

Posted by Jeff Henshaw on June 8, 2008
In the initial case, the failure was occurring reliably during xTaskCreate() before the scheduler ran, so I agree, it's not a context switch issue.

No IRQs are firing that are attempting to do a context switch at the time of failure. Single stepping the assembly code showed the exception being generated inside vListInsertEnd(), not from something an ISR did. Unless an ISR can run "invisibly" while single stepping assembly inside the debugger...

Same compiler, environment, etc. This stuff built & ran a couple days ago before I upgraded the RTOS.

Only one queue/semaphore usage that needed to be changed (it's still early days on my project), that was in macb.c and I took that function from the demo code that's part of the RTOS 5.0.2 distribution.

RE: V5.0.2 on AVR32 generates data exceptions

Posted by Jeff Henshaw on June 9, 2008

Never mind, I'm an idiot.

I have code that tests the SDRAM by filling it and then reading back & checking the fill values. Somehow I managed to move the call to this to AFTER a couple taks had been created, thus trashing everything that had been malloc'd already, including the task ready list that appeared to be the problem.

Amazingly, not trashing memory seems to make things work just fine. :-)

Thanks for your time!

[ 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