I have a program that has 6 task, 4 of these tasks will run based on a combination of hardware and software events while the other 2 are set to run periodically. I will give them names below to make my explanation a bit clearer:
Task A1 - This task will run if Mode A is selected on a dip switch at power up time. It is
controlled with an event group
Task A2 - This task is will run if a software event occurs in Task A1. It is also controlled with
an event group
Task B1 - This task will run if Mode B is selected on a dip switch at power up time. It is
controlled with an event group
Task B2 - This task is will run if a software event occurs in Task A1. It is also controlled
with an event group
Task WD - This task is used to control an internal watchdog. Runs periodically
Task 4-20 - This task is used to control an external 4-20 chip. Runs periodically.
When I comment out one of the 4-20 tasks everything works great and is scheduled/executed exactly as I expect. If I am running in Mode A and comment out one of the Mode B tasks everything works as expected. If I am running in Mode B and comment out one of the Mode A tasks everything works as expected. The issue comes when I run in either Mode A or Mode B with all tasks created. When I do this the system will behave as expected until the 4-20 task is given a time slice. At that point the system will freeze. I have removed all of the task code from the 4-20 task and have just added a vTaskDelay() to rule out some code I have written in that task causing the issue and the system still freezes. Initially this seemed like a memory issue, but I was able to run all of these tasks individually with significantly smaller stack sizes than I have set now and they have behaved as expected individually. I have also added guards when the tasks are created to ensure all of the tasks are created properly. If there is any other information that you need please let me know.
For some reason when I include only a function to change an LED value in the 4-20 task the system doesn’t freeze. The freezing only seems to occur when I use vTaskDelay().
Monitor the xTickCount variable. Does it keep inrementing when you hit the freeze? Alternatively, can you check whether your timer interrupt is being invoked in the frozen state?
When the system freezes up the xTickCount variable doesn’t increase. It doesn’t freeze at a value either, it comes up as not identifier not found. I am not sure how to check if the timer interrupt is being invoked but I have attached a screenshot from tracealyzer showing the freeze.
The processor I am using has an MPU which I believe would keep Tracealyzer from tracking the ISR. Task #7 is the 4-20 task that currently just vTaskDelays() for 2000 ticks. I’m not quite sure how that would be claiming the critical section.
possibly a misconfiguration of your maxsyscall level or a faulty implementation of some port function if you do not use the crit section explicitly. But I assume you are beyond configuration issues…
Note that the culprit is not necessarily the 4-20 task, it may simply be a catalyst to expose an elsewhere problem.
I’m definitely not ruling out being beyond configuration issues I’m pretty new at this lol. I am using a TI processor using the Arm Cortex-R4F. The FreeRTOS source files that were produced by the HAL tool included a config header file that does not include any mention of configMAX_SYSCALL_INTERRUPT_PRIORITY or configKERNEL_INTERRUPT_PRIORITY. Is this normal or am I missing something?
Note that the culprit is not necessarily the 4-20 task, it may simply be a catalyst to expose an elsewhere problem.
This was my thinking as well, I am just trying to track what may be causing that issue in that task specifically as other tasks are also using the vTaskDelay function but the issue is always after the 4-20 task is called.
Are you able to debug this one? Have you defined configASSERT and enabled stack overflow checking? Can you share code snippets or a minimal project showing the problem?
I have defined configASSERT to disable interrupts and pause. I’m not sure if I have overflow checking enabled, is that in the config header file? When I put a breakpoint before the vTaskDelay() in the last task that runs before the system freezes I am able to step through the whole process with no errors showing. This seems like it would indicate that there is some conflict with the ISR but I’m not sure how to go about confirming or fixing this.
Can you check where your PC register points to at freeze time? It is typically either at the hard fault handler infinite loop or somewhere in the idle task.
When I pause the debugger while the system is frozen this is what I get on the program counter. I can add a break point else where if you need more information.
The rest is commented out. If there is nothing I can try now based on the information that I have provided I can try and replicate the bug in a project with the proprietary code removed.
ok, so it is not a system deadlock but a fault. There is a standard check list to work off in that case - do implement the stack overflow checks. Also, we need to know what your maxsyscall priority is - if it is not in your freertosconfig.h, it must be somewhere else. In that turn, also let us know what the priorities of all your isrs are.
Is all your driver code part of the FreeRTOS distribution, or was some ofnit provided by your board manufacturer?
@mercera You really should post code as code.
Use 3 tildes ‘~’ or backticks ‘`’ to enclose multi-line code blocks and the </> button for intraline code. Thanks !
I am going to add the stack over flow checks now. I have searched the entire work space for configKERNEL_INTERRUPT_PRIORITY and configMAX_SYSCALL_INTERRUPT_PRIORITY and there is only once instance of configMAX_SYSCALL_INTERRUPT_PRIORITY and it is in a comment and there is no mention of configKERNEL_INTERRUPT_PRIORITY anywhere.
