Hi,
I am having a problem where a GateMutexPri doesn't seem to be stopping a task from entering a critical section of code when another task already (seemingly) has the gate.
Software/Hardware:
- TI-RTOS 1.01.00.25 (SYS/BIOS 6.34.04.22)
- XDC Tools 3.24.6.63
- Code Composer Studio 5.5
- TI Compiler 5.0.6
- LM3S9D92 custom board
Details of the problem:
The problem manifests itself when two tasks attempt to call Event_pend() causing an xdc runtime error. This should never happen as the code that calls the Event_pend() is resource locked by using a GateMutexPri.
Of the two tasks in question one, is priority 16 (task_high) and one is priority 12 (task_low). When the problem occurs, according to the ROV window, task_low has the gate and task_high is pending on the event. Under normal operation the same task that is pending should also have the gate (and this does normally work).
I've used the TI provided Logger in order to get more information regarding what is going on in the system. The code also fails the same way without any logging instrumentation.
Here is what happens:
Initially state of tasks:
task_high is pending on an event (EVT_inverter_cntl)
task_low is running
1. task_low calls the function
2. task_low logs that it is going to enter the gate
2.1 somewhere in here the hardware timer goes off that runs the tick.
2.2 the hardware timer also calls a clock function that posts EVT_inverter_cntl event causing the scheduler to run and a switch making task_high ready and a switch to run
3. task_high calls the function
4. task_high logs that it is going to enter the gate
5. task_high indicates through the log that it entered the gate
6. task_high pends on EVT_SBLink_ORQ, this causes a switch to have task_low run
7. task_low indicates through the log that it entered the gate
- This shouldn't happen if task_high did properly acquire the gate. I would expect task_low to block here and task_high to run until it leaves the gate.
8. task_low pends on EVT_SBLink_ORQ, this causes the XDC runtime error and ultimate application failure.
There is no way to pend on the event without acquiring the gate and there is no way to return from the function without leaving the gate.
If it is necessary I could probably post the actual code in question.
In order to replicate the failure I have to leave the application running overnight at the office. I've tried making a simple example application to replicate the failure to no avail.
The code looks something like this:
function {
log - about to enter gate
enter gate
log - entered gate
log - about to pend on event
pend on event
log - pended on event
leave gate
log - left gate
}
Any insight into the problem would be helpful. Thanks!
Edit: Is it possible that there is a critical section of code in GateMutexPti_enter that is not being protected in this case?
