• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 31 subscribers
  • Views 320 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

RM44L520: System Freeze, Possible Interrupt Config Issue

Andrew Mercer
Prodigy 170 points

Part Number: RM44L520
Other Parts Discussed in Thread: HALCOGEN

Hello, I have posted the first portion of this to the FreeRTOS Fourms and it seems that this issue is likely due to some issue in my interrupt configuration. Please see below:

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. I also tried replacing the vTaskDelay in the 4-20 task with a GIO set function and that works fine. I have attached a sample screenshot from tracealyzer showing the freeze:

I'm wondering if there is some issue with the interrupts that might be causing the context switching to be blocked. 

Please feel free to ask any questions. 

  • 0
    Prodigy 170 points

    For some reason the configMAX_SYSCALL_INTERRUPT_PRIORITY is not defined in the HALcogen provided FreeRTOSConfig.h file. Is this for some particular reason?

  • 0 in reply to Andrew Mercer
    Prodigy 170 points

    The freezing seems to be caused by an undefined instruction exception. When I pause my debugger in the freeze I get the following core register values:

    I have checked many of the common items that are reference on other posts for similar issues and haven't had any luck. Any help would be greatly appreciated. 

  • 0 in reply to Andrew Mercer
    TI__Guru**** 200256 points

    Hi Andrew,

    Yes, the M[4:0] = b11011 which means the CPU is switched to Undefined Instruction Mode. What is the value of R14_UND register?

    There are no Fault Status and Fault address registers associated with UNDEF exception; only Link register (R14_UND) provides relevant information. The instruction that caused the UNDEF abort is at R14_UND – 4.

  • 0 in reply to QJ Wang
    Prodigy 170 points

    Thank you for the response.

    The issue ended up being too little system stack assigned causing faults when the RTOS was context switching. Increasing the system stack size solved this issue.