Quality RTOS & Embedded Software

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


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 ]    [ Privacy ]    [ Sitemap ]    [ ]

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

Latest News

Version 10.1.0 of the FreeRTOS kernel is available for immediate download. MIT licensed.

View a recording of the "OTA Update Security and Reliability" webinar, presented by TI and AWS.


FreeRTOS and other embedded software careers at AWS.

FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

Espressif ESP32

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

Xilinx Microblaze and Zynq partner