New mutex crashing application!

Folks, Have been writing code happily on the STM32 for a few months, but I am trying to create a new mutex which is just crashing the application. Am creating it in exactly the same way as the two other mutexes I am using, but as soon as the scheduler starts I am just falling through to: DEFAULT_ISR_HANDLER HardFaultException Am using Rowley Crossworks. Anyone able to help me find why this is happening? I have put the following code in as a test to see whether the mutex is not being created. :         xLEDSemaphore = xSemaphoreCreateMutex();
        if (xLEDSemaphore == NULL)
            i = 6; However, it does not drop to the i = 6 line. I have created two other mutexes just fine and they’ve been working well. Most grateful for any pointers. :~) Rob

New mutex crashing application!

Do you have stack overflow checking switched on? As this is an STM32, are you absolutely sure you have the interrupt priorities set correctly. Take care especially with the way the interrupt priority is split into preemption bits as the STM32 libraries default differently to all the other Cortex base chips. Item number 3 here is often quoted in this forum http://www.freertos.org/FAQHelp.html Consider also using a malloc failure hook function although your check for null should catch that in your case.

New mutex crashing application!

I don’t have stack overflow checking, no. Do I understand correctly that each task would need to do its own checking? If I did switch this on I would still need to use uxTaskGetStackHighWaterMark in each task? I have tried creating the mutex in a couple of different tasks and also within an initialisation routine (not a task).  I am not evening using the mutex and I don’t see why the interrupts could have anything to do with it because of that. Memory usage does seem the most likely, but it seems pretty odd that I can try creating it in different tasks (one or two where there is no way I am anywhere near the stack size it has allocated to it) and it still falls over. If I understand correctly, the tasks have their own stacks and anything else is done from the heap. So, if you have an initialisation routine that is called once and never again, that would use the heap? As an aside, Is it bad practice to do the latter? Should all initialisations be done in the task itself before the infinite loop is reached?  Maybe I have a number of misconceptions here! Thanks for your help.

New mutex crashing application!

as the scheduler starts I am just falling through to:
DEFAULT_ISR_HANDLER HardFaultException Is xTaskStartScheduler() returning? If so you are running out of heap when the idle task is being created. If xTaskStartScheduler() is not returning, step through the code to find where the exception is happening. If you can’t do that then you can inspect the stack in the exception handler to find the PC value when the exception happened, but that is fiddly. If xTaskStartScheduler() is not returning, does the first task ever start?
xLEDSemaphore = xSemaphoreCreateMutex();
        if (xLEDSemaphore == NULL)
            i = 6;
However, it does not drop to the i = 6 line. But it is returning from xSemaphoreCreateMutex()?
don’t have stack overflow checking, no. Do I understand correctly that each task would need to do its own checking? If I did switch this on I would still need to use uxTaskGetStackHighWaterMark in each task?
Overflow trapping will only work during a context switch, so when the scheduler is running. It might not help then if you have a problem starting the scheduler. http://www.freertos.org/Stacks-and-stack-overflow-checking.html
If I understand correctly, the tasks have their own stacks and anything else is done from the heap. So, if you have an initialisation routine that is called once and never again, that would use the heap? As an aside, Is it bad practice to do the latter? Should all initialisations be done in the task itself before the infinite loop is reached? 
main() uses the stack from the linker script. Tasks have stacks allocated from the heap. Semaphores are allocated from the heap. Are you using heap_1.c or heap_2.c, or a different heap manager? If you are using heap_1.c or heap_2.c then the heap is statically allocated so the linker should take care of it. If you are using something else then it could be that the heap is being overflowed, or a linker script problem.

New mutex crashing application!

Is xTaskStartScheduler() returning? If so you are running out of heap when the idle task is being created. If xTaskStartScheduler() is not returning, step through the code to find where the exception is happening. If you can’t do that then you can inspect the stack in the exception handler to find the PC value when the exception happened, but that is fiddly. If xTaskStartScheduler() is not returning, does the first task ever start?
No, it’s not returning. It crashes in here. Specifically, it crashes in vPortStartFirstTask() which is within xPortStartScheduler().  As soon as it hits the first line of assembly languae – which is this: ” ldr r0, =0xE000ED08 n” /* Use the NVIC offset register to locate the stack. */ Then it falls over. I guess that would suggest a stack error?
main() uses the stack from the linker script. Tasks have stacks allocated from the heap. Semaphores are allocated from the heap.
Are you using heap_1.c or heap_2.c, or a different heap manager? If you are using heap_1.c or heap_2.c then the heap is statically allocated so the linker should take care of it. If you are using something else then it could be that the heap is being overflowed, or a linker script problem. I am using heap_2.c. I have been looking at SRAM use on Crossworks, but I am thinking it is meaningless as it says I am only using  eight bytes for the heap! I am not clear on how FreeRTOS asks for available SRAM. Crossworks says the .bss section is 18.6k and I assume that FreeRTOS is using this for its heap and stacks.  I guess seeing how much of this 18.6k is allocated and whether FreeRTOS is trying to use more than this might be the key. I am guessing that FreeRTOS doesn’t check to see whether the tasks hae asked for more than the available memory for its tasks and that Crossworks only complains if the amount of stack space claimed by FreeRTOS is more than the memory available. With all this in mind, we have two issues of are the tasks asking for too much memory at compile time (would this be flagged by Crossworks) and is one of the tasks trying to use more memory than it has been allocated. I don’t really buy  the latter, all of which would more suggest the heap is being  overstretched.  I’ll see if I can make the heap bigger.

New mutex crashing application!

OK, I have changed the  configMINIMAL_STACK_SIZE to be 100 (I was wondering how to do this as some of my tasks need nowhere near 120 bytes) and this has stopped it crashing. That would indicate my tasks are taking too much RAM I assume. This does mystify me as I have a lot of RAM available and not *that* many tasks! Yes, some of them I have allocated 240 bytes, but still, this shouldn’t get anywhere near 18k. I obviously don’t understand something  fairly fundamental. Thanks again, Dave. :~)

New mutex crashing application!

In fact, having counted, I have 18 tasks, most of which are allocated minimum task size, I am estimating my tasks are using around 3k. Some of the initialisation routines that are run once take several hundred bytes. I assume that the system uses memory from the heap for this and it’s then freed up so they shouldn’t be the issue(?).

New mutex crashing application!

I have been looking at SRAM use on Crossworks, but I am thinking it is meaningless as it says I am only using  eight bytes for the heap!
Read the memory management section of the FreeRTOS web site – or preferably in the FreeRTOS tutorial book.
OK, I have changed the  configMINIMAL_STACK_SIZE to be 100
That figure is in words, not bytes, so 100 will be 400 bytes of stack on a Cortex-M3.
That would indicate my tasks are taking too much RAM I assume.
?
In fact, having counted, I have 18 tasks, most of which are allocated minimum task size

In fact, having counted, I have 18 tasks, most of which are allocated minimum task size, I am estimating my tasks are using around 3k.
If configMINIMAL_STACK_SIZE is 100, and you have 18 tasks, then that is 18 * 400 = 7.2K bytes. 
Some of the initialisation routines that are run once take several hundred bytes. I assume that the system uses memory from the heap for this and it’s then freed up so they shouldn’t be the issue
? That would be a strange assumption, unless malloc() is being called anywhere.  I would assume that, if you are talking about stack usage during initialisation, then that memory would come from the stack. Again, I strongly suggest reading about memory management in FreeRTOS. Regards.

New mutex crashing application!

Thanks, for that Richard, I had totally missed that the minimal task size is in long, not bytes.
“That would indicate my tasks are taking too much RAM I assume.”
? I just meant that I was assuming my tasks/threads were demanding more RAM than was available. I guess it must have been that I Was right on the edge and the new mutex was taking me over it!
If configMINIMAL_STACK_SIZE is 100, and you have 18 tasks, then that is 18 * 400 = 7.2K bytes.
Which is still well below the 18.6k available, so I don’t understand where the rest of the memory is being eaten up. I’m still not clear, even having reread the memory management chapter (it has been a while since I’d read it!) where routines that run once and once only before the  scheduler starts take their memory from? ie Is it the heap or is there a stack assigned to all non-thread functions? Also, when you call routines from threads, do these routines take their temporary variable space from the heap? While I’m on, something I have wondered about. If you have a routine that can be called from more than one thread, if one thread is in the thread, the scheduler stops the thread and another routine calls the routine, what happens? I just can’t picture how the operating system deals with this. Does it  wait until a thread has exited from an external routine? Thanks again for your help and patience. :)