Interrupt Self-Nesting in CCES

Hi,

The programming reference describes a way of clearing the IMASKP bit, so that the same interrupt can again latch without being automatically cleared by the hardware.  The JUMP (CI) instruction clears the IMASKP bit for that interrupt, and the subsequent code runs at procedure level (not at an interrupt level).  We do not use the JUMP (CI) instruction as part of the CCES interrupt support.  If you use adi_int to install your interrupt handler then you cannot use JUMP (CI) as part of that handler, as it will impact the return sequence of the interrupt dispatcher and the correct operation of the CCES interrupt support.

I’m unsure what you mean by “So I have OS which is free of charge”, is this part of your question?

Thanks

JamesH

JamesH wrote:

I’m unsure what you mean by “So I have OS which is free of charge”, is this part of your question?

No, it's not the part of my question.

But I try to explain

I use the software interrupts like tasks. For example.

The background task (from main) do the file operations with SD-card and has the lowest priorites.

The software task 3 do communication with other blocks in my control system which demand the step in the range 10-100ms.

The software task 1 do the timer service with the step in the range 1second.

The software task 0 do work with the hard step in the range tens us (for example 20 or 40) and do the drive and semiconductor control part of the programm.

Also my program has the IO interrupt from SPI, SPORT0-7, EMI, general timers and timecore.

JamesH wrote:

If you use adi_int to install your interrupt handler then you cannot use JUMP (CI) as part of that handler, as it will impact the return sequence of the interrupt dispatcher and the correct operation of the CCES interrupt support.

It would be nice if ADI develop the interrupt handler which use jump (CI).

For example.

The timecore interrupt raise every 20us and it raise the software interrupt 0 with enabling of nesting interrupt.

The software interrupt 0 has the branched code and be delayed to execute the series of the high priority interrupts. So it make the situation when the one of the software interrupt 0 may be loose because the processor clear the interrupt bit in the register IRPTL. So I need to develop tools for decision of this problem.

Hi,

One possible way to avoid this situation is to use a lower-priority interrupt level to act as an intermediate interrupt.  For example, you could use software interrupt SFT2I for the actual work of your interrupt, then you could use SFT3I as an intermediate interrupt that simply raises SFT2I. 

So, here’s how it would look:

Timer Interrupt (handler):

                <do work>

                BIT SET IRPTL SFT3I;

<Return from interrupt>

SFT2I Interrupt (handler):

                <do actual work>

SFT3I Interrupt (app_IVT.asm hardware vector code):

.RETAIN_NAME ___int_SFT3I;           

___int_SFT3I:

                RTI (DB);                                // Just return…

                BIT SET IRPTL SFT2I;          // …setting SFT2I before you go.

                NOP; // 2nd delay slot

                NOP; // unused

.___int_SFT3I.end:

The SHARC hardware only clears the latch bit for the currently executing interrupt.  If you use SFT3I as the intermediate interrupt, then it will be possible for the Timer Interrupt to raise SFT3I whilst SFT2I is currently executing.  By doing this you should not lose an interrupt in the way that you describe.

We have encountered the same issue before on VDK (in VisualDSP) on SHARC, and we used the above SFT3I interrupt “trampoline” as a solution.

Please let us know if this helps.

Thanks

JamesH