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

Crashing in vListRemove

Posted by DiBosco on August 2, 2011
Folks,

I am writing to a queue which is four structures long. When I try to write a fifth structure into the queue, the application gives me a HardFaultException. If I follow it through I can see it crashes at this line in vListRemove:

pxList = ( xList * ) pxItemToRemove->pvContainer;

I am writing to the queue with this line:

xQueueSend(xEEPROMQueue,&EEPROMQueueData,portMAX_DELAY);

I thought that by using portMAX_DELAY it would just wait there until other parts of the OS free up the queue?

Anyone able to advise on how to fix this please?

Many thanks,

Rob

RE: Crashing in vListRemove

Posted by Richard on August 2, 2011
Start here:
http://www.freertos.org/FAQHelp.html

Then, if that does not help, please provide the information as per here:
http://www.freertos.org/FAQ-how-to-use-the-FreeRTOS-support-forum.html

Regards.

RE: Crashing in vListRemove

Posted by DiBosco on August 2, 2011
I did look through the documentation and couldn't find anything.

To give the information in the guide;

Micro is STM32, compiler is Rowley Crossworks, FreeRTOS version is the custom one Wittenstein did for me. The demos work fine, I've been using this for months with lots and lots of my own code, and it's this latest thing that is making it crash. I have not altered the source code of the OS itself in any way at all.

Everything works fine until I call this part of the code that attempts to write 24 values to EEPROM that were worked out according to a USB message I receive. If I take out the part that write to the EEPROM and therefore calls this write to the queue all is fine.

Hope that helps!

Rob

RE: Crashing in vListRemove

Posted by DiBosco on August 2, 2011
It's a stack thing, I must confess I don't understand the way memory management works properly. And yes, I have read the relevant part of the documentation, over and over.

RE: Crashing in vListRemove

Posted by Richard on August 2, 2011
You can turn run time stack checking on:

http://www.freertos.org/Stacks-and-stack-overflow-checking.html

and query stack high water marks:

http://www.freertos.org/uxTaskGetStackHighWaterMark.html


However, if you have purchased something from WITTENSTEIN, then you should have a log in to their support ticketing system. I have to confess to not being that keen on providing support for free when somebody else has been paid to provide it (unless you didn't take the support option?).

Regards.

RE: Crashing in vListRemove

Posted by DiBosco on August 3, 2011
Thanks, Richard. What I am not clear about is when a task calls a routine that is sat outside of its infinte loop (and could be called by other tasks), where does the memory for that external routine come from? Is it the calling task's stack or does it take memory out of a global stack or the heap maybe or some other way?

One other thing that I wonder about is, if you are calling a routine which is running outside of the thread whrn the tick occurs and you switch to another task does the scheduler wait until that called routine is exited? Also, what if a second task tried to then call that routine? Should I be using mutexes for routines that could be called by more than one task?

I didn't take any support with Wittenstein, no. It's been fairly plain sailing with FreeRTOS, it's very easy to use and very well documented for the vast majority of things. Really, the one and on;y thing I have had problems with is stack overflow I think!

Thanks for your help.

Rob

RE: Crashing in vListRemove

Posted by Richard Damon on August 3, 2011
A "routine" runs in the execution context of that which calls it, so when a tick interrupt occurs, you are not "outside of a thread". Just because the subroutine isn't written as part of the task function doesn't place the code "outside the task" when the task calls it.

Wether the routine needs a mutex to protect it depends on what the routine does. Since it runs in the context of its caller, if it is called from different threads, each one will have its own set of automatic (stack based) variables. If it accesses and global resources (global or static variables, or hardware) then those MAY need to protected by a mutex (or something). If the thread "owns" that resource already, then it probably doesn't (and then typically the thread will pass an id for that resource into the routine).

There is one exception to the concept of everything running in the context of its caller, and that is for callers that specifically setup new contexts for the routine, like the Create Task routine, which creates the new context for the task to run in, and possibly interrupts which may or may not set up a distinct context for the interrupt to run in, or may use the context of the task they interrupted, and if they perform a context switch, may return to the context of a different task.

RE: Crashing in vListRemove

Posted by DiBosco on August 3, 2011
PK, thanks, Richard. That is quite clear now and explains why what seemed like a very simple routine with very few variables was overflowing its stack. Thanks again. :~)


[ 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