DSP/LINK MSGQ messages preempting HWI thread ?

John Wilkes

Other Parts Discussed in Thread: OMAPL138

Hi,

I have an issue using message queue across DSP/LINK between the ARM and DSP on a OMAPL138. The ARM sends and the DSP receives. On the DSP side I want the message reception to be low priority because the DSP is doing more important real time stuff on a HWI thread (generated from a CLK object). I have task (TSK) that runs only once at start up and opens the DSPs message queue with no notification set by passing NULL to the MSGQ_open attrs argument. like this:

/* Open Queue */

Uint16 status = MSGQ_open ("DSPMSGQ0", &localMsgq, NULL);

I then have an idle task (IDL) defined which polls to see if a message is available by using MSGQ_get with zero timeout, like this:

if (MSGQ_get (localMsgq, (MSGQ_Msg *)&message, 0) == SYS_OK) {

/* Process Message Here */

...

}

Now, this all works OK in that the messages are received, processed and acted upon. However, every so often (not all the time) I get a failure in the code running in my HWI thread when a message is sent. It is as if something in DSP/LINK is preempting the HWI thread when a message is posted by the ARM. Is this the case? Does something with a higher priority than my CLK thread get called when a message is posted? If so, can it stopped? If not, can anyone suggest what else is happening?

Cheers,

John.

over 13 years ago

0 Karl Wechsler over 13 years ago

TI__Mastermind 20805 points

Hi John --

When the Arm sends the DSP a message, the Arm triggers and interrupt on the DSP. This ISR is probably preempting your HWI thread. You can change the interrupt disable bits for the CLK HWI ISR to disable all other interrupt when the CLK ISR is running. This should keep the other interrupts from preempting the CLK ISR. You might have to replace 14 with the id for the interrupt you are using. Check the CLK module in gconf to see the interrupt id.

bios.HWI.instance("HWI_INT14").interruptMask = "all";

You should verify mask setting for other ISRs in your system. I think the DSP/LINK code is provided and you can see how this ISR is defined. Not sure if DSP LINK defines this ISR in the .tcf or at runtime. Search for "HWI" in the source code.

-Karl-

0 John Wilkes over 13 years ago in reply to Karl Wechsler

Expert 1315 points

Hi Karl,

Excellent. Thank you for your reply, setting the mask to 'all' solved the issue. The only difference is that my system uses HWI 15 for the CLK module (I think because it uses a different hardware timer).

For the record I did some digging in the DSP/LINK source code (always a bit dangerous when you don't really understand what's going on!) and found this: The DSP/LINK interrupt is assigned in the 'HAL_intRegister' function in the hal_interrupt.c file (DA8XXGEM variant for my target) with a call to the DSP/BIOS API 'HWI_eventMap'. The interrupt vector is one of the arguments for this call but it is set in a structure that is initialised by the ARM. I gave up trying to find the place in the ARM code where this is set and in the end added the following debug to my Linux code, just before the 'PROC_start' call is made to start the DSP :

/* DEBUG */

printf ("DSP INTERRUPT VECTOR : %lx\n", LINKCFG_config.dspConfigs[processorId]->ipsTables[0][0].dspIntVectorId);

printf ("DSP INTERRUPT NUMBER : %lx\n", LINKCFG_config.dspConfigs[processorId]->ipsTables[0][0].dspIntId);

My code is based upon the message sample supplied with DSP/LINK so 'LINKCFG_config' and 'processorId' are as defined in this. The result is:

DSP INTERRUPT VECTOR : 4

DSP INTERRUPT NUMBER : 5

So I think that means that DSP/LINK uses HWI 4 to signal the DSP. In my application it doesn't actually matter since I do not want any interrupts active during my CLK thread, so setting the mask to 'all' is OK. I include this in case it helps anyone else. And to justify the time I spent surfing the code to find this out.

Thanks again for your help.

Cheers,

John.

Processors

Processors forum

DSP/LINK MSGQ messages preempting HWI thread ?