TMS320C6678: Lost wake up problem using Task_setPri(...)

Niklas Winter

Part Number: TMS320C6678

Context:

I am implementing a module which can be used for intercore communication/synchronization. I decided to implement my own module and not using the provided "Notify" module because I need to meet certain requirements:

We need to support an active waiting mode (polling) and sleeping mode (inactive SYS/BIOS task)
The algorithm needs to remember all interrupts which have been invoked (even if they haven't been served)
Performance is crucial
The performance requirement led us to implement a non-interruptive algorithm (Interrupts are only served if a SYS/BIOS task is inactive)

Implementation:

Our implementation is based on the IPCGR and IPCAR registers. The IPCGR registers are used to invoke a hardware interrupt, and their source bits are used for counting the interrupts. The IPCAR registers are used for the acknowledgement. Hardware interrupts are only enabled when a task is put to sleep. A task is put to sleep when no interrupt has occurred so far. To do so, we use the following code snippet:

if (no_interrupt) {

Hwi_enableInterrupt(INT_NUM);

Task_setPri(taskH,-1);

Hwi_disableInterrupt(INT_NUM);

}

The interrupt service routine for waking up the task again works as follows:

void wakeUp() {

Task_setPri(taskH,15);

}

Questions:

Our approach comes along with some drawbacks. For instance, we can't remember an arbitrary number of interrupts, only 8 tasks distributed equally over the individual cores can communicate with each other, the IPCGR registers can not be used for something else and so forth. However, right now the module does what it is expected to do and all tests are passing without failure. However, I've got one question I haven't been able to answer so far:

Is the function Task_setPri(...) within the "Task" module "atomic" in regard to hardware interrupts? If not, I could imagine that there might be the potential of a lost wake-up error, and certainly I don't want to risk this error. Let's imagine that a hardware interrupt is invoked immediately before the Task_setPri(taskH,taskPriority) function is executed. This event would lead the task to sleep forever if only one interrupt is invoked. If this might be a problem, I would also be interested in workarounds to avoid this kind of error.

over 2 years ago

0 Shankari G over 2 years ago

TI__Mastermind 25535 points

Niklas,

Let me have a look at it and get back.

Regards

Shankari G

0 Niklas Winter over 2 years ago in reply to Shankari G

Prodigy 120 points

Well, I found out that it does lead to a lost wake-up problem. However, we could use hook functions. To be more specific, we can specify a switch-hook function which is executed during the transition between two tasks. If I use this switch-function I can disable and enable hardware interrupts and be sure that my former task has already been put to sleep. But this leads to one new question: