Software and user interrupts on F2802x

Hi Santosh,

Looking at both the TRAP and INTR instructions both mention that they are not affected by the INTM bit. However, if execution of these instructions occurs when already in an ISR this would mean that the ISR for the TRAP/INTR would vector immediately, instead of following the return of the calling ISR, as a non-nested maskable interrupt normally would. It is this behaviour (of the maskable interrupts) that I would like to have execute.

i.e. On normal execution within the first ISR, the ISR completes without executing the TRAP instruction and returns to normal code which then continues executing. However if some condition is present during the execution of this first ISR, then a branch means that the TRAP (or equivalent) *is* executed, BUT IT'S ISR DOES NOT EXECUTE IMMEDIATELY, execution within the first ISR continues until it returns as normal, only then should the interrupt referenced by the TRAP actually execute, then when that is completed , it returns and normal code execution continues...

So really it's like emulating what happens when a maskable interrupt occurs when another maskable interrupt's ISR is already executing, such that the second interrupt is "queued" after the end of the first interrupts execution.

Is that possible on this device?

Thanks

Toby,

The TRAPs are user defined software interrupts they should carry lower priority than the peripheral (maskable) interrupts. The INTM masks all maskable interrupts so if a TRAP is pending while no other higher priority interrupts are pending then the TRAP would get executed.

Did you try using one of them in any peripheral ISR to check if the TRAP execution is getting nested?

The SYSBIOS support HWI (Hardware Interrupts) and SWI (software interrupts), if you want to look at using them.

Best Regards

Santosh

Hi Santosh,

I have tried adding TRAP #11 and INTR #11, with a isr address placed in 11.1 in the PIE vector table, followed by EINT; ERTM;

However, it appears as if the TRAP (or INTR) is running immediately and for some reason vectoring to the ISR_ILLEGAL routine. In fact it appears as if the TRAP is running before the TRAP instruction is even reached!!

I placed a break point in the assembly well before the TRAP yet the breakpoint is not stopped at, but execution still vectors to ISR_ILLEGAL as soon as interrupts are enabled (EINT;), with 0x0DE in the PIECTRL register, the address of INT11.1.

Without the TRAP instruction the program runs without issue.

Thus not only does the TRAP or INTR not wait until the end of the current, higher priority interrupt, it does not seem to want to vector to the assigned ISR!!

My code is as follows

main.c:

static interrupt void pit_isr (void) {
    // Do some isr stuff here...
}

void initPIT (void) {
    EALLOW;
    PieVectTable.PIE11_RESERVED = &pit_isr;
    EDIS;
    PieCtrlRegs.PIECTRL.bit.ENPIE = 1;
    PieCtrlRegs.PIEIER11.bit.INTx1 = 1;
    IER |= M_INT11;
}

void main (void) {
    // setup, etc...
    initPIT();
    EINT;
    ERTM;

    for(;;) {
        // super loop stuff here...
    }
}

DPL_ISR.asm:

_DPL_ISR:
    ; Do a context save of XAR, etc

    ; A breakpoint placed here never gets stopped at, but the TRAP inside PIT 1 still causes ISR_ILLEGAL
    ; Some other work....
    PIT 1 ; call macro that has TRAP instruction
    ; More work and context pop
    IRET

PIT.asm:

PIT	.macro n
    INTR    #11 ;Placed at start for test for now
    ; Some other PIT work
    .endm

I tried with TRAP #20 for USER1 as well but the same results ensued.

Using SYSBIOS is not feasible at this stage of the project and is also a lot more system than is needed for the project requirements.

Thanks

Ah, I was writing to the wrong vector table location, should have been:

PieVectTable.rsvd11_1 = &pit_isr;
// not
PieVectTable.PIE11_RESERVED = &pit_isr;

This was causing the ISR_ILLEGAL as *its* vector was still in the location I thought I had overwritten.

Nevertheless, it still appears that the TRAP #11 is causing an interrupt to vector immediately... :(

I have been testing software interrupts and managed to get the behavior Toby was looking for (2 years ago admittedly) by manual setting the IFR bit instead of using the INTR or TRAP instructions from inside an ISR.

I tried both using a PIE interrupt channel (INTX.Y) , making sure that the corresponding peripheral connected to INTX.Y did not trigger the relevant PIEIFRX.Y bit, and using CPU INT13 which is directly connected to the CPU instead of going through the PIE. Both ways worked for me, i.e. the SW-triggered ISR was called right AFTER the ISR that triggered it returned.

More specifically what I tested succesfuly is as follows:

Setup:

Configure some HW interrupt to trigger HW_ISR()

Set INTX.Y vector to SW_ISR(), the software-triggered ISR.

Select an interrupt channel INTX.Y for the SW-triggered interrupt and PIEIERX.Y=1, IER.X=1

Make sure that the peripheral that INTX.Y is connected to is not triggering the interrupt

Execution:

1. A HW interrupt triggers HW_ISR()

2. HW_ISR() starts executing and sets PIEIFRX.Y

3. HW_ISR() completes execution normaly and returns

4. SW_ISR() is triggered (need to acknowledge the PIE interrupt here)

I consulted the C28x CPU and intstruction reference guide ( latest version here ) toget the above working, though I have to mention that it was a bit tricky because is the guide "User" and "Software" interrupts mostly refer to thethe ITRAP and INTR instructions.

Wow, well done Giannis!

TBH I cant remember what I was trying to use this with now, nonetheless thanks for reporting your solution and well done! :)