AM5726: DSP unable to detect interrupt after moving it from GPIO1_4 to GPIO3_15

I've been doing some more troubleshooting to try to determine the root cause of this issue, but haven't had any luck so far.  I tried implementing the solution posted in this forum post: https://e2e.ti.com/support/processors-group/processors/f/processors-forum/568662/linux-am5728-gpio5-not-accessible-from-the-dsp1-core-with-linux-running-on-the-am5728 as follows:

    volatile uint32_t * p_clktrctrl_reg = (uint32_t *)(CSL_DSP_L4PER_CM_CORE_REGS + CSL_L4PER_CM_CORE_COMPONENT_CM_L4PER_CLKSTCTRL_REG);
    CSL_FINST(*p_clktrctrl_reg,
             L4PER_CM_CORE_COMPONENT_CM_L4PER_CLKSTCTRL_REG_CLKTRCTRL,
             SW_WKUP);

    volatile uint32_t * p_gpio3_clkctrl_reg = (uint32_t *)(CSL_DSP_L4PER_CM_CORE_REGS + CSL_L4PER_CM_CORE_COMPONENT_CM_L4PER_GPIO3_CLKCTRL_REG);
    CSL_FINST(*p_gpio3_clkctrl_reg,
              L4PER_CM_CORE_COMPONENT_CM_L4PER_GPIO3_CLKCTRL_REG_MODULEMODE,
              AUTO);
    while (CM_L4PER_GPIO3_CLKCTRL_MODULEMODE_AUTO !=
            CSL_FEXT(*p_gpio3_clkctrl_reg,
                     L4PER_CM_CORE_COMPONENT_CM_L4PER_GPIO3_CLKCTRL_REG_MODULEMODE));

This code is called when the DSP program starts, however, the CLKTRCTRL setting doesn't stay at SW_WKUP. It gets set to this value for a few seconds before being reset to HW_AUTO. I'm wondering if there's a Linux driver somewhere that's still trying to manage GPIO3 in some manner, or if there's some other power or clock mode somewhere that I'm not correctly configuring. 

The signal I'm expecting to see on GPIO3_15 is a short, square pulse that occurs every millisecond. I put a scope on a PCB via to make sure that this signal is being generated, and I was able to see the signal. This leads me to believe that the problem is somewhere in our software, and not in the hardware.

Is this issue still open for you?

Hi Josue, this issue is still open

Hello Jon,

I apologize for the long wait. A couple of questions to get started:

I would like to clarify a couple of things: 

• 1.

  Jon Lake said:

  triggering input from GPIO1_4 to GPIO3_15

  On your input for the old code,

  Jon Lake said:

  CSL_xbarDspIrqConfigure(1, CSL_XBAR_INST_DSP1_IRQ_55, CSL_XBAR_GPIO3_IRQ_1);

  Is this supposed to be CSL_XBAR_GPIO1_IRQ_1?

  • 2. On the new code, did you mean to change the IRQ Input line from 55 to 57? (CSL_XBAR_INST_DSP1_IRQ_57)

  Did you enable this new input line from the interrupt controller? or could this be a typo?

  -Josue

Hi Josue,

Thanks for your response, here's what I have in my notes for approaches we tried:

1. You're correct, I made a typo on my old code and it should be CSL_XBAR_GPIO1_IRQ_1

2. I did intend to change the IRQ input line from 55 to 57; looking at Table 17-3 of the AM572x TRM showed that DSP_IRQ_57 defaults to GPIO3 Interrupt 1, which seemed to be what the GPIO drivers in the processor SDK expected. One complication I noticed with this setup is that somehow our event crossbar (found with omapconf dump) has a MAILBOX assigned IRQ 57 that is apparently being used for some remoteproc MessageQ messaging our application needs, so I also tried moving GPIO3 back onto interrupt line 55 and modifying the GPIO driver to use 55 for GPIO3, but this didn't seem to fix our issue either despite allowing our messaging to function properly again.

-Jon

Jon,

What is the value of the IRQ_CROSSBAR Configuration Register for  CTRL_CORE_DSP1_IRQ_56_57[24:16]?

or in the case of 55,   CTRL_CORE_DSP1_IRQ_54_55[24:16]?

-Josue