Crashing in vListRemove

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

Crashing in vListRemove

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.

Crashing in vListRemove

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

Crashing in vListRemove

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.

Crashing in vListRemove

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.

Crashing in vListRemove

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

Crashing in vListRemove

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.

Crashing in vListRemove

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. :~)