vTaskStartScheduler() hangs the system on QEMU

Kernel
1

Hello, I’m trying to run a FreeRTOS demo on a custom QEMU emulated board, CPU is Cortex-M7. Everything seems to be working just fine, but as soon as I try to launch the scheduler the system hangs, none of the newly created tasks will go in execution nor do I get a fail on the call (if that happened the instructions after vTaskStartScheduler() would be executed).
I changed config parameters in FreeRTOSConfig.h multiple times, unfortunately without any success. I’m new to FreeRTOS, what do you think would cause vTaskStartScheduler() to hang?

Thanks in advance!

2

FreeRTOS startup, invoked by vTaskStartScheduler(), contains several configASSERT() statements to help developers configure and integrate FreeRTOS correctly. Depending on how configASSERT() is defined, it might be the cause of the hanging you observe. Can you look in FreeRTOSConfig.h to see how configASSERT() is defined?

3

Thank you for your reply Jeff!
configASSERT() is defined in the following way:

#define configASSERT(x) if((x)==0) { __asm volatile ( " cpsid i " ::: “memory” ); for( ;; ); }

4

With that definition, the most likely explanation is a configASSERT() statement is hanging due to a configuration error. If you are using a debugger, you can use it to stop execution while it is hanging, and you can see which configASSERT() statement has identified the configuration error. If you don’t have a debugger, you can probably use a different definition of configASSERT() that allows QEMU to exit gracefully with a report about the failed assertion. See here for an example.

5

Thanks a lot for the suggestion!
I’ve tried to follow the example that you shared and, while using GDB, I found out that the assertion that identifies the error is in GCC/ARM_CM7/r0p1/port.c at line 331, which contains the following code:
configASSERT( pxVectorTable[ portVECTOR_INDEX_SVC ] == vPortSVCHandler );

If I comment out that instruction or I define configCHECK_HANDLER_INSTALLATION 0 to skip all those checks, the system seems to be stuck in the infinite loop of the default handler. Before going in the default handler, the last function executed was prvPortStartFirstTask().

6

Which shows the problem, you somehow haven’t configured your system to install the FreeRTOS SVC Handler into the interrupt vector table.

How you do this depends very much on the full tool-chain you are using.

1 Like
7

You’ll have to get the vector table sorted out to get FreeRTOS up and running.

Here is the vector table in the example project I linked earlier. Take particular note of the vPortSVCHandler, xPortPendSVHandler, and xPortSysTickHandler, which must be in your vector table for FreeRTOS to function in its most common configuration.

If you can’t find your vector table in your project, then it might be provided for you by the tools and would likely be CMSIS compliant. In that case, you can #define the 3 handlers to their CMSIS names so they will be properly installed into the vector table. Something like this:

#define vPortSVCHandler SVC_Handler
#define xPortPendSVHandler PendSV_Handler
#define xPortSysTickHandler SysTick_Handler
3 Likes
8

That was it! Thank you so much Jeff and also to you Richard, you’ve both been of great help. I had to add #define vPortSVCHandler SVC_Handler, now everything works correctly.

1 Like