NMI in DSP/BIOS on TMS320C6713B

Samti Rubinti

Other Parts Discussed in Thread: TMS320C6713B

Hi,

I work with CodeComposer3.3 using DSP/BIOS on TMS320C6713B.

I have the following question:

Is it may be a problem to branch from NMI routine (by updating the PC with the NRP value) into a task routine that waits on SEM_pend command?
If there is a problem can you please recommend an approach to address this issue.

The code example attached below.
Following description happens after main is done.

/*
Timer1 is called upon timer1 interrupt.
*/
void Timer1(void)
{
SEM_post(&handler);
}

/*
Task1 waits on Sem_pend() until the semaphore is released by "Timer1()".
*/
void Task1(void)
{
while(1){
    SEM_pend(&handler, SEM_FOREVER);

    /* ... Some more work */
}
}

/*
WatchDog() may be called if NMI happens (during "...Some more work").
If WatchDog is called then "Branch(void)" (below) sets the ProgramCounter to "Task1(void)" using the reference to "Task1(void)" as the address.
*/
void WatchDog(void)
{
IRQ_nmiEnable();

Counter++;

branch(&Task1);
}

/*
_branch is assembly code as follow:
*/
_branch:

mv      A4, B1
mvc   .S2 B1, NRP

b        NRP
nop    5

.end

Best Regards

Samti Rubinti

cinlab

over 13 years ago

0 ScottG over 13 years ago

TI__Mastermind 26780 points

Samti,

I think you will hit two big problems doing this.

The first one is that when an NMI is invoked it can “break into” sections of code that needed interrupts disabled, and which cannot be safely resumed after taking the NMI. This is particularly a problem for code that uses “multiple assignment” of register values, that leverage expected pipeline delays. This includes software pipelined loops that had intentionally started with an interrupt disable. It will also break code that uses delay slots of branch instructions for creating short atomic sections.

On earlier architecture C62x and derived devices like C67x, an NMI was really intended as a means to gracefully shutdown or restart the processor after a critical error. Not for application resynchronization purposes.

Newer C64x+ devices have added exception handling and a bunch of status bits so that if an NMI fires, software can check to see if it may be safe to resume. But there are still some corner cases that may not be fully recoverable.

The second problem is that just setting the PC to where you want to go to will not properly restore stack and other register values to be back in that task. I thinks stacks will grow abnormally and the code that was preempted won't resume properly. If the program doesn’t crash immediately I think it eventually will.

The option I’d recommend is to dedicate a “normal” interrupt for this purpose, and don’t use NMI.

Scott

0 Samti Rubinti over 13 years ago in reply to ScottG

Prodigy 20 points

Scott,

Thanks a lot for answering my questions.

Regarding the first issue. I had the thought in the same direction you described but, without the detailed knowledge that you gave, of course. The remedy you suggested is understood but I will have to see if that is feasible.

Second issue does happen - namely, the stack overflowed eventually. But, since large enough stack is assigned and since NMI expect to happen for the most just few times before doing full reset, the system can live up to it.

Thanks again

Samti

Processors

Processors forum

NMI in DSP/BIOS on TMS320C6713B