This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TMS570LS3137: Testing the interrupt priority remapping

Expert 1995 points
Part Number: TMS570LS3137
Other Parts Discussed in Thread: HALCOGEN

Hello all,

I wanted to test the remapping of the interrupt by using the function vim. To evaluate the effectiveness of the remapping I thought about the following scenario:

1) The RTI-interrupt drives periodically the status of a GIO output to be True for 100 ms and False for the next 100 ms. The result is a square wave with 200ms of period.

2) A big computational load is executed when a GIO input goes to True. The computation consists in a 10M for-loop empty iterations.

3) Initially a higher priority is given to the GIO input (and then to the associated for loop) than the RTI-interrupt.

The effect of the above described scenario is having a 200ms square wave that gets stacked to the last logical value for approx 1 second when the GIO input occurs. It works and the code is the following:

#include "sys_common.h"

/* USER CODE BEGIN (1) */
#include "system.h"
#include "sys_vim.h"
#include "het.h"
#include "gio.h"
#include "rti.h"
/* USER CODE END */



/* USER CODE BEGIN (2) */
uint32 x;
/* USER CODE END */

int main(void)
{
/* USER CODE BEGIN (3) */

    vimInit();
    _enable_IRQ();
    vimEnableInterrupt(2,SYS_IRQ);
    vimEnableInterrupt(23,SYS_IRQ);

/*Swap the default priority of the RTI with the default priority of the GIO(B) input */ vimChannelMap(2,23,&rtiCompare0Interrupt); vimChannelMap(23,2,&gioLowLevelInterrupt); rtiInit(); rtiEnableNotification(rtiNOTIFICATION_COMPARE0); gioInit(); gioEnableNotification(gioPORTB, 2); gioSetBit(gioPORTB,3,1); rtiStartCounter(rtiCOUNTER_BLOCK0); /* USER CODE END */ return 0; } /* USER CODE BEGIN (4) */

/*To generate the square wave*/
void rtiNotification(uint32 notification) { x++; if (x % 2 == 1) { gioSetBit(gioPORTA,4,1); } else { gioSetBit(gioPORTA,4,0); } }

/*computational load (approx 1s delay)*/ void gioNotification(gioPORT_t *port, uint32 bit) { if (port == gioPORTB) { uint32 i = 0; for (i=0;i<10000000;i++); } }

In Halcogen, aside from changing the period of the RTI compare 0 to 100ms and setting the GIO output intended to use, the settings in the screenshots were applied to the VIM tab and the GIO input used as "external" source of interrupt:

Now, I would like to resume the original priority with the RTI over the GIO, and expect that even if the input occurs the square wave shall "kill" it at the occurrence of the 200ms square wave, than the only part that I change in the code is the following:

vimChannelMap(2,2,&rtiCompare0Interrupt);
vimChannelMap(23,23,&gioLowLevelInterrupt);

but unfortunately it produces the same effect: again, the 200ms square wave is delayed by the for-loop at the occurrence of the input. What's wrong in the priority assignment or in the test scenario?

Thanks ahead for any reply.

Regards.

  • Hello,

    Please note that the Cortex R4/R5 processors do not support nested interrupts natively. That is, once the CPU starts servicing an IRQ service routine, it can only be "interrupted" by a higher-priority exception. This higher-priority exception can be an FIQ, or an abort, or a reset, but not another IRQ.

    The priority assignment in the VIM only applies when multiple interrupts are pending. If you do need the RTI interrupt to "kill" the service routine for the GIO interrupt you can either configure the RTI as an FIQ or look into enabling nested interrupts. In case you enable nested IRQ servicing, the software is responsible for managing the stack for the return addresses. See this application note and code example for more information: 

    Regards,

    Sunil

  • Hello Sunil,

    Thanks for your reply.

    I suppose that the same happens when I have multiple IRQ and FIQ: an FIQ kill the running IRQ but it is not killed by the next FIQ even if the priority in VIM of this second FIQ is higher than the first one. Is it right?

    Regards.

  • Yes, that is correct. Once the CPU switches over to the FIQ mode ("M" bits in CPSR) further responses to FIQ are automatically disabled. This response to FIQ requests can be re-enabled in software, in which case the software is responsible for managing the context save/restore.

    Regards, Sunil