I’m using the GCC/ARM_CM3 port of version 7.1.0. My startup code creates tasks and other FreeRTOS objects, and does much other initialization before calling vTaskStartScheduler. It’s locking up during the init. I think the heap_2 memory allocation is attempting to invoke the scheduler before it starts. I believe it goes something like this:
I call xTaskCreate (or create a queue or whatever), which calls pvPortMalloc in heap_2.c. This calls xTaskResumeAll.
Because other tasks have already been created, xTaskResumeAll manages the ready/pending list and possibly sets xYieldRequired. I suspect it is then calling portYIELD_WITHIN_API, which calls vPortYieldFromISR and invokes a context switch before I’ve called vTaskStartScheduler. The application locks up.
I think it might work if I were to somehow make sure that interrupts can never be enabled before the scheduler starts. Instead, I worked around it by creating just one task, starting the scheduler, and doing the rest of my init within the task.
Is this “expected” behavior, or should I have been able to do all my initialization before the scheduler starts?