dsplib functions disable interrupts.

As a side note our newer devices (c674x) contains core improvements to help in this sort of situation.  Specifically it has a buffer called the SPLOOP (software pipelined loop) which allows the very tight loops to be interruptible.  It also produces better code density.

Thanks for that guys.

I've resolved this issue by using the dMAX to transfer my samples to ping-pong buffers.

I believe what was happening as that an external bus master sitting on the UHPI was preventing the DSP core from servicing the MCASP RX register in a timely fashion occasionally.

Since the dMAX is a higher priority than both the DSP core and the UHPI external bus master, this would therefore generally align with the fact that using the dMAX to service the MCASP I never get any missed MCASP rx events. It's also allowed me to pump much much higher data rates through the DSP and actually reduce the amount of consumed CPU time - which is pretty much the result you'd expect.

Oh - and it's allowed me to use the FFT code in DSP lib - which is again much much faster than the results vis-a-vis just compiling straight C.

Job well done by the ASM guys !

Hi,

everybody says: "Not interruptible", but nobody says why. For my project (based on 6416T) I've developed the Fast Walsh-Hadamard Transform function in assembler. I followed all the C calling convention requirements. But when I run the function with interrupts enabled, I get wrong result, while running one with interrupts disabled provides the correct output. I guess, the problem is not in my code, but in DSP/BIOS interrupt handlers: after some interrupt some register gets corrupted. This also explains why some DSPLIB functions require interrupts to be disabled. So, why some DSPLIB functions are not interruptible? Thank you in advance.

Alexey,

The reason why:

The DSP uses an instruction pipeline, and it can execute multiple instructions in one clock cycle.  When a developer of an optimized library routine makes assumptions about how many clock cycles it takes to do a certain task, or a certain series of instructions, those assumptions will not be valid when an interrupt occurs.  The instruction pipeline gets flushed when control is transferred to the interrupt handler, and again when the interrupt handler returns control to the main thread.

Steve

Alexey Kurbanov said:

I guess, the problem is not in my code, but in DSP/BIOS interrupt handlers: after some interrupt some register gets corrupted. This also explains why some DSPLIB functions require interrupts to be disabled.

No, the issue is definitely not in BIOS.  That code is extremely well tested and robust.  Steven made some good points in his post (thanks!) but I'd also like to mention "multiple assignment" as a key reason for needing to disable interrupts.  More info on multiple assignment here:

C6000 Programmer's Guide

If your code uses multiple assignment then you will be required to disable interrupts within your code.

Another common mistake is improper handling of the stack pointer.  It must always be aligned to an 8 byte boundary.  You can not have it unaligned for even a single cycle.  In other words you cannot push things on to the stack one word at a time or the stack will be temporarily unaligned.  This will cause data to get corrupted.

Anyway, those are a couple thoughts.  Your code would be better if the assembly code itself disabled interrupts rather than relying on the application to do it as a precondition.

Hi guys,

thanks a lot for the explanations. I think I have to re-read the TMS320C6000 Programmer’s Guide carefully once again.