Hi, I am facing a Hardfault problem. And I trace it and find out it is caused by the last line of the xPortStartScheduler function which should not be executed in normal cases. I still have no idea how it goes to the last line.
Here are some pics: Last line of xPortStartScheduler and Register Info
be careful, your debugger may mislead you - normally, the address on the stack frame back traced is the next instruction’s address, so your fault may likely have occurred without the function returning. Can you single step from xTaskScheduler() and see how far you come before faulting? Will a breakpoint on your sys tick handler be called?
Edit: Of course, it is also possible that system start up fails and exits the startup function (typically due to memory allocation failure), but that scenario rarely ends up in a fault.
Dose xTaskScheduler() means vTaskStartScheduler()?
I create a task for initialization, when the code runs at the Motor_init(), the systick handler can be called, but other tasks can not. And when I use Run in debug mode, the task can only be executed once, but using single step it can be executed twice
What other tasks are you creating? What do you mean “the task can only be exectued once?” First of all, your task does not run an infinite loop but exits which is sort of unusual - you can do that, but there a some pitfalls in it. In any case, “running it twice” does not make sense, where would you create a second instance of it and why?
The first task is to send a sync message througn Can bus to my torque sensor and motors. The second task is to send the received data from sensor and motors to Usart, these data are stored by two queues respectively.
I use CAN2_RX0_IRQHandler to receive the data on Can bus, and it runs successfully.
I may describe it improperly. When I debug, the Task_Sync goes first, sending the sync messages. Then goes the Task_Uart, but the queue doesn’t store the data, and when I step over the osDelay(40), the Hardfault occurs.
From this screenshot, it looks like you are using a mix of FreeRTOS-Kernel APIs uxQueueSpacesAvailable and CMSIS-RTOS APIs osDelay. Are you using any wrapper layer to translate RTX APIs to FreeRTOS-Kernel APIs?
If you are not using using any wrapper layer to translate CMSIS-RTOS APIs to FreeRTOS-Kernel APIs and the intention is to use FreeRTOS-Kernel APIs then try replacing osDelay with vTaskDelayUntil and see if that helps?
I am not asking you to change your code base, just to test something to possibly narrow down the cause. osDelay() is not a native FreeRTOS function, so what it does is up to anyone’s guess unless we see the implementation.