Other Parts Discussed in Thread: DP83869
Tool/software:
I am working to validate the PRU to R5F Host Interrupt communication.
In my setup, I generate an INT from the PRU to the R5F and measure the response time.
It's a very clean setup with no other applications running (on same cores):
- PRU event number (EVENT#17) ->
- -> pr0_pru_mst_intr[1]_intr_req (EVENT#17)->
- -> Channel #3 ->
- -> Host Interrupt #3 ->
- -> Host Interrupts 2 through 9 exported from PRU_ICSSG and mapped to device level interrupt controllers ->
- -> PRU_ICSSG0_PR1_HOST_INTR_REQ_1 -> CMPEVENT_INTRTR0_IN_1 (ID#1) ->
- -> PRU_ICSSG0_PR1_HOST_INTR_PEND_1 (INT#121)
On the PRU, I toggle a debug I/O when I generate the INT and I do the same on the R5F inside the interrupt service routine.
What I experience is a non-deterministic delay ranging from 460 ns to 560 ns.
What could be the cause of this so high delay?
And what could be causing the random response time?
There any way to fix it?
PRU Code:
set GPIO_OUT, GPIO_OUT, PIN_DEBUG0 ; set del pin di debug LDI INT_REQ, prk_pru_mst_intr1_intr_req ; prk_pru_mst_intr[1]_intr_req clr GPIO_OUT, GPIO_OUT, PIN_DEBUG0 ; clear del pin di debug
Mapping:
R5F Host Interrupt Service Routine
/* PRU FW IRQ handler */
void pruIrqHandler(void *args)
{
GPIO_pinWriteHigh(CONFIG_GPIO23_CODE_READER_0_TRIGGER_PIN_baseAddr, CONFIG_GPIO23_CODE_READER_0_TRIGGER_PIN);
...
Configuration:
#define ICSSG_PRU_INT_NUM ( CSLR_R5FSS0_CORE0_INTR_PRU_ICSSG0_PR1_HOST_INTR_PEND_1 ) // VIM interrupt number (INT#121)
...
// Register & enable ICSSG PRU FW interrupt
HwiP_Params_init(&hwiParams);
hwiParams.intNum = ICSSG_PRU_INT_NUM;
hwiParams.callback = &pruIrqHandler;
hwiParams.args = 0;
hwiParams.priority = 0; // 0h = Highest priority
hwiParams.isPulse = FALSE;
hwiParams.isFIQ = FALSE;
status = HwiP_construct(&hwiObj, &hwiParams);
DebugP_assert(status == SystemP_SUCCESS);
