Hello,
Got an issue with task dynamically allocated. It works fine to use xSemaphoreMutexStatic() and xCreateTaskStatic(). Once using xSemaphoreMutex() and xCreateTask(), then no tasks are running.
Dynamic allocation is configured as 1 and the heap size is configured as (size_t)(8*1024). heap_4.c is included in the project.
The return value of xCreateTask() is ok. But once it is created and then other tasks stop running.
What could be the potential cause?
Thanks!
Crane
Can you break the code in the debugger and see what it is doing when it appears stuck?
Have you defined configASSERT and enabled stack overflow checking?
If the xCreateTask() was called PRE scheduler, then one possibility is that FreeRTOS just did not start as it failed to be able to create one of its built in tasks (Idle, and perhaps the Timer if needed).
What do you mean “break the code in the debugger”? It gets stuck after the scheduler is called. How to track what’s happening in this case?
Yes, configASSERT is defined and overflow check is configured as 1.
Idle task is created successfully statically. (Static allocation is also configured).
Timer task is not configured.
Scheduler is started. Then the program appears stopped as no task is running then.
Do you have some debugging setup to step through the code? If yes, you can usually pause the execution in the debugger.
You mean single step, break point? Yes, the program stops after the scheduler is called. What are the methods to track afterwards?
Can you share callstack when the program appears hang?
Is this the call stack you want to see?
Today I tried to run from flash, then it causes software interrupt after calling the scheduler.
Are you able to step into the function xPortStartScheduler?
What code causes the software interrupt? What error do you get?
Yes, I am able to step into it.
Then it get stuck in here: portRESTORE_FIRST_CONTEXT().
If it is run from flash, the software interrupt is caused by this function. It called Interrupt_illegalOperationHandler().
Which FreeRTOS port is this and where did you get it from?
Can you step through the assembly of portRESTORE_FIRST_CONTEXT and find the instruction that is causing the exception?
It is for TI C28x from C2000Ware SDK provided by TI.
No, no matter stepping into or stepping over, sometimes it calls Interrupt_illegalOperationHandler() and sometimes the program just stops and both buttons of “step into” and “step over” are in grey.
Can you check with port.c file does it use? It should be present in FreeRTOS/portable directory. I am trying to see if you are using one of the official port or a port supplied by the vendor.
I am using FreeRTOSv202112.00. It is the latest version and doesn’t have the port for C28x.
The port I am using is actually posted on the internet first and recently it is included by TI in their C2000Ware SDK. Suppose it should work fine.
The question is, if it have potential problem, is there any way to debug to find it out?
An update.
Right now, the only issue is when the build configuration is set as RAM and the task is created statically, it will cause software interrupt. Otherwise, the tasks are running properly except the new task.
Anyway, the issue raised in the first post in this thread is addressed. I found it is relevant to the priority level of the new task.
Yes - the way would be to find the faulting instruction and figuring out the cause of fault.
Does the hardware provide any more information about the software interrupt?
Yes understand. But how to do that when the program gets stuck and neither stepping into nor stepping over is available?
What do you mean “hardware”?
That depends on the core - different architecture provide different ways. Suggest you to reach TI as you are using a port vended by TI.
The microcoltroller architecture.
Ok, thank you.
It works fine when the program is built for FLASH, no matter if the task is created statically or dynamically.
When the program is built for RAM, it works in a certain scenario and didn’t work most time .
I am afraid that the issue is relevant to linker file.
