• State Resolved
  • Locked Locked
  • Replies 10 replies
  • Answers 1 answer
  • Subscribers 32 subscribers
  • Views 234 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

AM2612: Routing GPIO interrupts to PRU core

Ichikawa Tatsuya
Prodigy 70 points

Part Number: AM2612
Other Parts Discussed in Thread: SYSCONFIG

 

Hello,
I am working with the following environment:
    Device: AM261x LaunchPad
    SDK: motor_control_sdk_am261x_10_02_00_07
    IDE: CCS 12.8.1
 
We aim to assign the interrupt of GPIO124 to System Event 62 of ICSS0-PRU1 on a custom board.
 
Currently, as shown below, the R5F application acts as an intermediate and notifies ICSS0-PRU1 of System Event 62.
If we want to notify ICSS0-PRU1 directly from GPIO124 without using the R5F application as an intermediary, what changes would be required?

GPIO124 is defined in SysConfig as follows:
    PIN Direction: Input
    Trigger Type: Falling Edge
    Enable Interrupt Configuration: OFF
    Pull Up/Down: No Pull
    Slew Rate: Low
    Invert: OFF
    Qual Sel: Sync

The GPIO INT XBAR is configured as follows:
    XBAR Output: GPIO_MUX_124
    XBAR Instance: GPIO_INT_XBAR_VIM_MODULE0_0

In the R5F application:
    HwiP_Params_init(&hwiPrms);
    hwiPrms.intNum      = 164;
    hwiPrms.callback    = irq164_handler;
    hwiPrms.args        = 0;
    hwiPrms.isPulse     = TRUE;
    hwiPrms.isFIQ       = FALSE;
    status              = HwiP_construct(&gPruIcssHwiObject0, &hwiPrms);
    DebugP_assert(status == SystemP_SUCCESS);
    HwiP_enableInt(164);

    isrpinNum = 124;
    bankNum = GPIO_GET_BANK_INDEX(isrpinNum);
    gpioBaseAddr = (uint32_t) AddrTranslateP_getLocalAddr(CSL_GPIO0_U_BASE);
    GPIO_bankIntrEnable(gpioBaseAddr, bankNum);

In the interrupt handler:
    void irq164_handler(void *args)
    {
        uint32_t isrpinNum = (uint32_t) args;
        uint32_t bankNum   = GPIO_GET_BANK_INDEX(isrpinNum);
        uint32_t intrStatus;
        uint32_t gpioBaseAddr;

        gpioBaseAddr = (uint32_t) AddrTranslateP_getLocalAddr(CSL_GPIO0_U_BASE);
        GPIO_bankIntrDisable(gpioBaseAddr, bankNum);

        /* Get and clear bank interrupt status */
        intrStatus = GPIO_getBankIntrStatus(gpioBaseAddr, bankNum);
        GPIO_clearBankIntrStatus(gpioBaseAddr, bankNum, intrStatus);

        /* Notify to PRU1 */
        PRUICSS_sendEvent(gPruIcss0Handle, ICSS_INTC_EVENT_62);
        PRUICSS_clearEvent(gPruIcss0Handle, ICSS_INTC_EVENT_62);

        /* Enable interrupt */
        GPIO_bankIntrEnable(gpioBaseAddr, bankNum);
    }

  • 0
    TI__Guru 62160 points

    Yes, you can eliminate the R5F intermediary entirely by using the PRU-ICSS XBAR to route the GPIO124 interrupt directly into the PRU-ICSS0 interrupt controller as a system event.

    You can use this example as reference: EPWM Protection PRU Example - ICSS Connectivity

    Architecture Overview

    The AM261x PRU-ICSS0 has 16 external interrupt inputs (PRU_ICSSM0_INTR_IN_0 through PRU_ICSSM0_INTR_IN_14), each fed by a corresponding PRU-ICSS XBAR output (PRU-ICSS_XBAROUT_0 through PRU-ICSS_XBAROUT_14) 1. These external inputs map to specific system event numbers within the PRU-ICSS INTC.

    Required Changes

    Step 1: Reconfigure the XBAR Routing

    Remove the current GPIO INT XBAR configuration that routes to GPIO_INT_XBAR_VIM_MODULE0_0 (which targets the R5F VIM).

    Instead, configure the PRU-ICSS XBAR to route GPIO_MUX_124 to one of the PRU-ICSS XBAR outputs. For example, route it to PRU-ICSS_XBAROUT_0, which feeds PRU_ICSSM0_INTR_IN_0.

    In SysConfig, look for the PRU-ICSS XBAR (not GPIO INT XBAR) and configure:

    • XBAR Input: GPIO_MUX_124
    • XBAR Output: PRU-ICSS_XBAROUT_0 (or any available output 0–14)

    Step 2: Map the External Input to System Event 62 in PRU-ICSS INTC

    The external input PRU_ICSSM0_INTR_IN_0 arrives at a specific system event number within the PRU-ICSS INTC. You need to verify which system event number corresponds to INTR_IN_0 in the TRM's PRU-ICSS internal event mapping table, then map it appropriately.

    If the external input does not directly correspond to System Event 62, you have two options:

    1. Remap your PRU firmware to respond to whichever system event INTR_IN_x maps to (instead of event 62)
    2. Choose the XBAR output whose corresponding INTR_IN maps to system event 62

    Step 3: Configure PRU-ICSS INTC

    In your R5F initialization code, configure the INTC to map the system event to a channel and host interrupt that PRU1 monitors 1:

    /* Example INTC configuration */
// 1. Map the system event (from INTR_IN) to a channel (e.g., channel 1)
// 2. Map channel 1 to Host Interrupt 1 (which connects to R31 bit 31 on PRU1)
// 3. Enable the system event
// 4. Enable the host interrupt
// 5. Enable global interrupts

PRUICSS_intcInit(gPruIcss0Handle, &pruicssIntcInitData);

    The PRU-ICSS INTC programming model requires 1:

    1. Set polarity/type (high/pulse)
    2. Map event → channel via ICSS_INTC_CH_MAP_REGi
    3. Map channel → host interrupt via ICSS_INTC_HINT_MAP_REG
    4. Clear and enable the interrupt
    5. Globally enable interrupts

    Step 4: Remove R5F Interrupt Handler

    Remove entirely:

    • The HwiP_construct / HwiP_enableInt(164) code
    • The irq164_handler function
    • The GPIO bank interrupt enable/disable logic

    Step 5: PRU1 Firmware

    Your PRU1 firmware detects the interrupt via R31 register bits (bit 30 for Host Interrupt 0, bit 31 for Host Interrupt 1) 1. Ensure your PRU firmware polls or waits on the correct R31 bit corresponding to the host interrupt you mapped.

    Summary Table

    Component Current (R5F intermediary) New (Direct routing)
    XBAR GPIO_INT_XBAR → VIM_MODULE0_0 PRU-ICSS XBAR → PRU-ICSS_XBAROUT_x
    R5F ISR irq164_handler + PRUICSS_sendEvent Removed
    PRU-ICSS INTC Event 62 triggered by software Event triggered by hardware via INTR_IN_x
    Latency GPIO → R5F ISR → PRU event GPIO → PRU event (hardware only)

    Important Note

    Verify in the AM261x TRM (Table 10-19) 1 which internal system event number each INTR_IN_x maps to. If none directly maps to event 62, adjust your PRU firmware to use the actual event number assigned to your chosen INTR_IN_x input, or select the INTR_IN that corresponds to event 62.

    1. AM261x Technical Reference Manual - PRU-ICSS INTC and Interrupt Map
    2. MCU Plus SDK - PRUICSS Driver API Guide
    3. EPWM Protection PRU Example - ICSS Connectivity
  • 0 in reply to Nilabh Anand
    Prodigy 70 points

    Thank you for your support.

    Following your guidance, I made the revisions below, but I was unable to detect an interrupt on PRU1 R31 (bit 30: Host Interrupt 0).
    What could be wrong?

    1. Removed the GPIO INT XBAR.

    2. Added ICSS XBAR instead.
        XBAR Output: GPIO_MUX_124 ("gpio_int_xbar")
        XBar Instance: ICSS_XBAR_ICSS_MODULE_0

    GPIO_INT_XBAR
        XBAR Output: GPIO_MUX_124
        XBar Instance: GPIO_INT_XBAR_ICSS_XBAR_0

    3. Removed the following processing from the R5F application:

    • The  code HwiP_constructHwiP_enableInt(164)
    • The  function irq164_handler
    • The GPIO bank interrupt enable/disable logic

    4. Configured the following in ICSSM0 INTC Internal Signals Mapping:
        ICSSM Instance: ICSSM0
        INTC MODE: ICSSM0_MII_RT_EVENT_DISABLE
        INTC Event Signal: 32: PRU_ICSSM0_PR1_SLV_IN_0
        INTC Channel: Channel 2
        INTC Host Interrupt: Host Interrupt 0
        System Event Polarity: HIGH
        System Event Type: PULSE

    Best regards

  • 0 in reply to Ichikawa Tatsuya
    TI__Guru 62160 points

    Hi,

    Apologies for the delay here, let me get back on this by today eod.

  • 0 in reply to Nilabh Anand
    TI__Intellectual 1980 points

    Hi,

    Can you share me values of below registers without adding GPIO bank interrupt enable/disable logic:- 



    I believe you need to keep the code related to GPIO bank interrupt enable, can you please share me same register values after enabling GPIO bank interrupt.

    You need code to clear GPIO interrupt then clear INTC event in PRU itself, we can check this once you we see event getting detected in RAW_STATUS & ENABLE_STATUS registers. 

    Thanks & regards,
    Manoj.

  • 0 in reply to Manoj Koppolu
    Prodigy 70 points

    Thank you for your support.

    The register values ​​for the two cases are as follows.

    Case 1: without adding GPIO bank interrupt enable/disable logic
        ICSSM_PR1_ICSS_INTC_INTC_SLV_RAW_STATUS_REG1 : 0x00000000
        ICSSM_PR1_ICSS_INTC_INTC_SLV_ENA_STATUS_REG1 : 0x00000000
        ICSSM_PR1_ICSS_INTC_INTC_SLV_ENABLE_REG1 : 0x00000001
        ICSSM_PR1_ICSS_INTC_INTC_SLV_ENABLE_CLR_REG1 : 0x00000001

    Case 2: after enabling GPIO bank interrupt
        ICSSM_PR1_ICSS_INTC_INTC_SLV_RAW_STATUS_REG1 : 0x00000000
        ICSSM_PR1_ICSS_INTC_INTC_SLV_ENA_STATUS_REG1 : 0x00000000
        ICSSM_PR1_ICSS_INTC_INTC_SLV_ENABLE_REG1 : 0x00000001
        ICSSM_PR1_ICSS_INTC_INTC_SLV_ENABLE_CLR_REG1 : 0x00000001

    Best regards.

  • 0 in reply to Ichikawa Tatsuya
    TI__Intellectual 1980 points

    I see PRU_ICSSM0_PR1_SLV_IN_0 event is enabled at ICSS INTC, but the event is not detected either in RAW status or Enabled status.

    Can you check below two register values to check XBAR settings are correct: - 

    GPIO_XBAR_OUT_0 should be mapped with Input 124 (GPIO_MUX_124): - (0x52E02004 + (124*4)), expected value: - 0x1007C
    PRU_ICSS_XBAR_OUT_0 (PR1_SLV_INTR_0) should be mapped with input 47 (GPIO_XBAR_OUT_0): - (0x52E03004 + 0*4), expected value: - 0x1002F

    If you see the values as expected, it means we need to check if the interrupt is getting generated from GPIO or not.

    Thanks & regards,
    Manoj.

  • 0 in reply to Manoj Koppolu
    Prodigy 70 points

    Thank you for your support.

    I checked the values ​​of the GPIO_XBAR_INTR_MUXCNTL and ICSSM_XBAR_INTR_MUXCNTL registers.
    The results are as follows:

      GPIO_XBAR_INTR_MUXCNTL:
        0x52E02004 + (0*4) = 0x0001007C
        0x52E02004 + (124*4) = 0x00000000

      ICSSM_XBAR_INTR_MUXCNTL:
        0x52E03004 + (0*4) = 0x00010000

    Your previous answer indicated (0x52E02004 + (124*4)), but the expected value was actually stored at (0x52E02004 + (0*4)).
    Is this correct?
    Since the GPIO_XBAR_INTR registers region is 256 bytes, I think (0x52E02004 + (124*4)) falls outside the valid range.

    Also, I set the value of ICSSM_XBAR_INTR_MUXCNTL to 0x1002F, but the event is still not being detected.

    Best regards

  • 0 in reply to Ichikawa Tatsuya
    TI__Intellectual 1980 points
    Ichikawa Tatsuya said:
    Your previous answer indicated (0x52E02004 + (124*4)), but the expected value was actually stored at (0x52E02004 + (0*4)).
    Is this correct?

    you right, you should check at 0x52E02004 + (0*4) only, since we mapped interrupt to GPIO_XBAR_OUT_0.

    Can you also enable GPIO interrupt to R5F & check if this event is being detected in ICSSM_PR1_ICSS_INTC_INTC_SLV_RAW_STATUS_REG1 (expected value: - 0x1).

    I will try on hardware if you are seeing event is not detected in RAW_STATUS after this.

    Thanks & regards,
    Manoj.

  • 0 in reply to Manoj Koppolu
    Prodigy 70 points

    Thank you for your support.

    I set the registers as follows:

        GPIO_XBAR_INTR_MUXCNTL: 0x52E02004 + (0*4) = 0x0001007C

        ICSSM_XBAR_INTR_MUXCNTL: 0x52E03004 + (0*4) = 0x0001002F

    After enabling the GPIO interrupt in the R5F application, the value of the `ICSSM_PR1_ICSS_INTC_INTC_SLV_RAW_STATUS_REG1` register became `0x1`.
    However, the interrupt is still not being detected at bit 30 of the R31 register on the PRU side.

    For reference, GPIO124 is configured as follows in SysConfig:

        PIN Direction : Input
        Trigger Type : Falling Edge
        Enable Interrupt Configuration : ON
        Pull Up/Down : No Pull
        Slew Rate : Low
        Invert : OFF
        Qual Sel : Sync
        GPIO Peripheral : GPIO124/A19

    Meanwhile, the ICSSM0 INTC Internal Signals Mapping is configured as follows;
    is this correct?

        ICSSM Instance : ICSSM0
        INTC MODE : ICSSM0_MII_RT_EVENT_DISABLE
        INTC Event Signal : 32: PRU_ICSSM0_PR1_SLV_IN_0
        INTC Channel : Channel 0
        INTC Host Interrupt : Host Interrupt 0
        System Event Polarity : HIGH
        System Event Type : PULSE

    I am concerned about the fact that the System Event Type is set to `PULSE` on the PRU side, even though the GPIO is configured for a Falling Edge trigger.

    Best regards

  • +1 in reply to Ichikawa Tatsuya
    Prodigy 70 points

    Hi, Manoj.
    Thank you for your support.

    The reason the interrupt was not detected at bit 30 of the R31 register on the PRU side was that the interrupt had not been cleared in the ICSSM_PR1_ICSS_INTC_INTC_SLV_STATUS_CLR_INDEX_REG register.
    This resolved the issue.