• State
  • +1 person also asked this people also asked this
  • Replies 5 replies
  • Subscribers 102 subscribers
  • Views 148 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

AM6442: PRU to R5F Host Interrupt Performace

Francesco Rolando
Prodigy 20 points
Part Number: AM6442
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): 

  1. PRU event number (EVENT#17) ->
  2. -> pr0_pru_mst_intr[1]_intr_req (EVENT#17)->
  3. -> Channel #3 ->
  4. -> Host Interrupt #3 ->
  5. -> Host Interrupts 2 through 9 exported from PRU_ICSSG and mapped to device level interrupt controllers ->
  6. -> PRU_ICSSG0_PR1_HOST_INTR_REQ_1 -> CMPEVENT_INTRTR0_IN_1 (ID#1) ->
  7. -> 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:

Fullscreen
1
2
3
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
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

Mapping:

R5F Host Interrupt Service Routine

Fullscreen
1
2
3
4
5
/* 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);
...
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

Configuration:

Fullscreen
1
2
3
4
5
6
7
8
9
10
11
12
#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);
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

  • 0
    TI__Mastermind 37818 points

    Hi Francesco,

    The assigned expert is out of office for this and next week. Responses to this thread will be delayed.

    Thanks for your patience.

    Regards,

    Tushar

  • 0 in reply to Tushar Thakur
    TI__Expert 6825 points

    Hi Francesco,

    Thank you for the detailed explanation.

    Just wanted to check if you are still facing this issue or were you able to figure it out?

    Regards,

    Nitika

  • 0 in reply to Nitika Verma
    Prodigy 20 points

    No, unfortunately I still haven't understood the cause of the delay. As for the fact that it appears to be random, it seems to be related to other applications running on different cores, but I have no idea how to intervene to eliminate or reduce the randomness of the response times.

  • 0 in reply to Francesco Rolando
    TI__Expert 6825 points

    Hi Francesco, 

    Francesco Rolando said:
    it seems to be related to other applications running on different cores

    What applications do you have running on the other cores in your system.

    I will try to reproduce this issue on my setup and look into it.

    Also, what is your KPI on the interrupt generation delay? 

    Regards,

    Nitika

  • 0 in reply to Nitika Verma
    Prodigy 20 points

    I'm using Industrial Communication SDK 9.2.0.15 with its MCU SDK. Below is the setup for my testing and validation project:

    • xmark_a53ss0-0 - Not yet used in my application but configured with a TI example:

    ti/ind_comms_sdk_am64x_09_02_00_15/mcu_plus_sdk/examples/kernel/freertos/posix_demo/am64x-evm/a53ss0-0_freertos-smp

    • r5fss0-0 - Not yet used in my application but configured with a TI example:

    ti/ind_comms_sdk_am64x_09_02_00_15/mcu_plus_sdk/examples/networking/lwip/cpsw_lwip_https (CPSW/DP83867)

    • r5fss0-1 - Not yet used in my application but configured with a TI example:

    ti/ind_comms_sdk_am64x_09_02_00_15/examples/industrial_comms/ethernetip_adapter_demo (ICSSG1/MII/DP83869_0+DP83869_1)

    • r5fss1-0 - Not yet used in my application - Not running

    • r5fss1-1 - My testing application about this case

    • icssg0-rtupru0 - Not yet used in my application - Not running

    • icssg0-rtupru1 - Used by my application but only uses resources inside ICSSG0

    • icssg0-pru0 - Not yet used in my application - Not running

    • icssg0-pru1 - My testing application about this case

    • xmark_icssg0-txpru0 - Not yet used in my application - Not running

    • xmark_icssg0-txpru1 - Used by my application but only uses resources inside ICSSG0

    When I stop the TI example running on r5fss0-0, the interrupt delay becomes more stable.

    Regarding the KPI, I'm able to transfer 32 bytes from MSRAM via XFR2VBUS in hundreds of nanoseconds, so I suppose it's reasonable to expect an interrupt response time of comparable -or maybe less- latency.

    These are my doubts:

    How much is the typical api/soc delay introduced by GPIO_pinWriteHigh?

    Could this be a measurement error due to the pin management by R5?

    If, not:

    How much is the soc's signals delay introduced from point 1) to point 7)?

    How much is the latency of VIM / HwiP_* api?

    What interrupt handling resources are shared between R5 cores?

    And finally, can the int management with VIM / HwiP_* api be deterministic?

    Thanks. F.