freeRTOS error - no idea what it is

Hi all,
I added a task through MPLAB Harmony V3 and suddenly the entire code stopped working and when debugging it seems stuck in the function below that seems to address the freeRTOS.
Attached is a picture of the call stack (cannot copy and paste the test).

Going back up the stack, it seems it might be originated by vTaskStartScheduler().

I have six tasks each allocated with 1024 bytes task stack buffer (I think that’s what it is called). But the micro has 512 KB of SRAM so it seems that’s not the case…
BUT how can I make sure that is definitely not the case?

No idea how to figure out what it is or how to fix it…

Help would be much appreciated…! :slight_smile:

void vApplicationMallocFailedHook( void )
{
   /* vApplicationMallocFailedHook() will only be called if
      configUSE_MALLOC_FAILED_HOOK is set to 1 in FreeRTOSConfig.h.  It is a hook
      function that will get called if a call to pvPortMalloc() fails.
      pvPortMalloc() is called internally by the kernel whenever a task, queue,
      timer or semaphore is created.  It is also called by various parts of the
      demo application.  If heap_1.c or heap_2.c are used, then the size of the
      heap available to pvPortMalloc() is defined by configTOTAL_HEAP_SIZE in
      FreeRTOSConfig.h, and the xPortGetFreeHeapSize() API function can be used
      to query the size of free heap space that remains (although it does not
      provide information on how the remaining heap might be fragmented). */
   taskDISABLE_INTERRUPTS();
   for( ;; );
}

This is going back up the call stack… It seems some task pointer NULL in task create??

	#else /* portSTACK_GROWTH */
	{
	StackType_t *pxStack;

		/* Allocate space for the stack used by the task being created. */
		pxStack = pvPortMalloc( ( ( ( size_t ) usStackDepth ) * sizeof( StackType_t ) ) ); /*lint !e9079 All values returned by pvPortMalloc() have at least the alignment required by the MCU's stack and this allocation is the stack. */

		if( pxStack != NULL )
		{
			/* Allocate space for the TCB. */
			pxNewTCB = ( TCB_t * ) pvPortMalloc( sizeof( TCB_t ) ); /*lint !e9087 !e9079 All values returned by pvPortMalloc() have at least the alignment required by the MCU's stack, and the first member of TCB_t is always a pointer to the task's stack. */

			if( pxNewTCB != NULL )
			{
				/* Store the stack location in the TCB. */
				pxNewTCB->pxStack = pxStack;
			}
			else
			{
				/* The stack cannot be used as the TCB was not created.  Free
				it again. */
				vPortFree( pxStack );
			}
		}

Hmm, not sure I can say much more than it already says in the comment you pasted in with the code. It is also documented on the page that describes FreeRTOS hook functions. Basically this function being called lets you know a call to pvPortMalloc() failed because you ran out of heap. As coded that hook function does nothing other than halt the program - but normally don’t want heap exhaustion to be a fatal error, but handled gracefully, so you can edit the function so it returns back to the application code.

Thank you Richard,
if I remove the new task it works. If I add it back in it doesn’t.

As mentioned the micro has 512Kb of SRAM and only a tiny amount is used by my application.

Also I only have 6 tasks. Adding the 7th gives that error.

Does that give you any more hints as to what might be causing it when the 7th task is added?

How can I see how much RAM the OS is using?

Thank you

Don’t forget to check the two links that @rtel gave you.

FreeRTOS has 5 different modules that can allocate memory ( heap ), which you find here.
Your project is using heap_1.c, which can only allocate space, it can not release is.
In some situations this is enough, but most applications also want to release memory by calling vPortFree().
A good module that can also free memory is heap_4.c
Mind you that you must define how much memory shall be allocated to the heap with configTOTAL_HEAP_SIZE ( defined in FreeRTOSConfig.h ).

ahah Thank you Hein and sorry Richard… :slight_smile:
Richard fully answered my question in his post but it was 2 in the morning and after 16 hours in front of the PC not sure what I read when read it…

Thank you again both