Hi all, I am new to FreeRTOS. I am using the xTaskNotifyWait() in the main task. the other task sends xTaskNotify() 1 time per second. I want to make sure the main task is running correctly. I use global var. to store and share the task handle after creation. The strangest is the notification can execute only once. First of all, I guess this is the issue about how I use the xTaskNotify()/xTaskNotifyWait(). Finally, I found the issue is the global var. was been changed. I had to make sure only the creation was written to this global var. I try to using xTaskGetHandle() to get once, it seems correct. This looks like the workaround. But I use the same method in ISR and xTaskGetHandle() seems can’t be called in ISR. What can I do? The task handle global var. can’t be trusted, the API can’t call from ISR. Any suggestion?
This is the problem to focus on. You won’t be able to make a meaningful program if you can’t trust your variables. One common cause of corrupt globals is stack overflow. Can you try increasing the size of the task’s stack and see what happens? Another sticky point for ARM Cortex MCUs is interrupt configuration. Is STM32Cube giving you any warnings during code generation?
Hi Jeff, thanks for your help. I double the size of the stack, now is 256(default was 128). It seems okay in the beginning, but after I execute few actions then it happens again. I think this is not the root cause. In fact, I didn’t implement so many features in the task. Another strange point is, I move the task function inside of freertos.c everything goes fine. But if I move the task function to the other c file, then it crashed. OMG!!
By the way, I didn’t see any warning message during the code generate.
I strongly recommend to define configASSERT and also enable stack overflow checking for development/debugging. It helps a lot !
If using e.g. any printf family function in your task even stack size of 256 might not be enough.
Of course it‘s also possible that your application code has a bug corrupting the global variable. Perhaps you should post the code creating the tasks and the task code.
hi Hartmut, thank u for ur wonderful advisement. I started to implement stack overflow checking function. Hope I can make the code stronger. For the configASSERT that is new for me. I just know the concept, but I still need time to get understand how it works.
By the way, I re-generate the code, I changed the configuration as below
4 tasks change to static creation.
Priority change, the default task set to idle, and the others are normal
For the issued task, I increase the task to 256, and the buffer also increases to 256. → that might be why I failed in the previous. I didn’t modify this together.
The FreeRTOS docs contain a good basic configASSERT example (the 2nd one) by just disabling all interrupts and stop in a forever loop.
So you can either put a breakpoint at the loop or when the application is stuck there, halt the target with the debugger and check the call stack to see the source location with the assert came from.