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
Thank you in advance!
Hi YYJ and welcome,
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
Yes, sorry, I meant vTaskStartScheduler().
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?
Do any of your ISRs run?
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.
Two tasks below:
Hi @YYJ,
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 use cubemx to generate this project, so I should all use cmsis API?
Can you try enabling Memory Management Fault, Bus Fault, and Usage Fault exceptions as described in this app note - https://www.keil.com/appnotes/files/apnt209.pdf?
Also, can you share your complete code which shows the problem?
As @urutva pointed out, your usage of osDelay() may be a problem. Have you tried replacing it with vTaskDelay() ?
But my new codes all use CMSIS APIs to avoid the mix of two APIs, but the Usage Faults occurs instead of Memory Manage Faults
I’m pretty sure that osDelay just wraps vTaskDelay. That shouldn’t cause any problems.
But did you define configASSERT and enabled stack checking ?
See FreeRTOS - stacks and stack overflow checking
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.
Thanks for your help, I find out my Device_Init Task is overflowed.
Thank you for reporting back.
