Tool/software:
Hello guys!
I have got a J721e_evm board. I am using the "ti-processor-sdk-rtos-j721e-evm-09_02_00_05". I am trying to trigger a GPIO interrupt which comes form an external source (like a button). I am using the mc2_1 core, and the PDK's GPIO example: main_led_blink.c. I have already successfully triggered interrupt from a WKUP domain GPIO, but with MAIN domain its just does't work. In my example I am trying to use GPIO0_71. I could use this pin as output successfully, but not as interrupt input so far. Here is the relevant part of my code:
pinmux_data:
/* MyGPIO0 -> GPIO0_71 -> AA28 */ { PIN_PRG0_PRU1_GPO8, PIN_MODE(7) | \ ((PIN_PULL_DISABLE | PIN_INPUT_ENABLE) & (~PIN_PULL_DIRECTION)) },
/* GPIO Driver board specific pin configuration structure */ GPIO_PinConfig gpioPinConfigs[] = { GPIO_DEVICE_CONFIG(1, 71) | GPIO_CFG_IN_INT_RISING | GPIO_CFG_INPUT, }; /* GPIO Driver call back functions */ GPIO_CallbackFxn gpioCallbackFunctions[] = { NULL }; /* GPIO Driver configuration structure */ GPIO_v0_Config GPIO_v0_config = { gpioPinConfigs, gpioCallbackFunctions, sizeof(gpioPinConfigs) / sizeof(GPIO_PinConfig), sizeof(gpioCallbackFunctions) / sizeof(GPIO_CallbackFxn), 0x8U
volatile uint32_t main_gpio_intr_triggered = 0; static void Board_initGPIO(void) { Board_initCfg boardCfg; GPIO_v0_HwAttrs gpio_cfg; boardCfg = BOARD_INIT_PINMUX_CONFIG | BOARD_INIT_MODULE_CLOCK | BOARD_INIT_UART_STDIO; Board_init(boardCfg); GPIO_socGetInitCfg(1, &gpio_cfg); gpio_cfg.baseAddr = CSL_GPIO0_BASE; (gpio_cfg.intCfg[71]).intcMuxNum = INVALID_INTC_MUX_NUM; (gpio_cfg.intCfg[71]).intcMuxInEvent = 0; (gpio_cfg.intCfg[71]).intcMuxOutEvent = 0; GPIO_socSetInitCfg(1, &gpio_cfg); } void AppMainGpioCallbackFxn(void) { main_gpio_intr_triggered = 1; GPIO_clearInt(0); } #if defined (RTOS_ENV) void gpio_test(void* arg0, void* arg1) { #else int main() { Board_initGPIO(); #endif // GPIO initialization GPIO_init(); // Set the callback function GPIO_setCallback(0, AppMainGpioCallbackFxn); // Enable GPIO interrupt on the specific gpio pin GPIO_enableInt(0); GPIO_clearInt(0); GPIO_log("\n -------------LED blink application------------- \n"); UART_printStatus("\n Awaiting interrupt occurrence ...\n"); AppDelay(DELAY_VALUE); while (main_gpio_intr_triggered == 0U); UART_printStatus("\n Button has been pushed, and the interrupt has been captured!! \n"); while(1) { AppDelay(DELAY_VALUE); } }
Hi,
To confirm, you are able to generate an interrupt for WKUP_GPIO and for Main GPIO with interrupt configured as output, but you are not able to generate an interrupt for Main GPIO configured as input?
Did both input and output configurations work for WKUP_GPIO?
How are you connecting GPIO0_71 to a button to trigger an interrupt?
Thanks,
Neehar
Yes, I can generate output in both WKUP_GPIO and also in MAIN_GPIO, but I can generate interrupt only in the WKUP_GPIO, not in MAIN_GPIO. I am using 4k7 ohm as a pulldown resistor (when I don't press button the pin is on 0V, when I press it, its on 3.3V). I have already checked the connection with multimeter a several times.
Hi,
I can generate output in both WKUP_GPIO and also in MAIN_GPIO
Does this mean output interrupt?
Can you provide the contents of the PADCONFIG register for GPIO0_71?
Thanks,
Neehar
I have already tried output interrupt: Connected a LED which I toggled from software.
Result: The LED was blinking but no interrupt has been occurred.
I have also tried input interrupt: Connected a button with pulldown resistor (as I wrote).
Result: No interrupt occurred.
Interesting that with bedugger I see the interrupt happening in the GPIOMUX_INTRTR0 registers, but Its not getting to my mcu2_1 core somehow. Maybe the interrupt routers connections are wrong.
Here is the padconfig (as I know PRG0_PRU1_GPO8 is represented at PADCONFIG72):
Hi,
Result: The LED was blinking but no interrupt has been occurred.
Did you configure a callback function and was it triggered with the LED?
Did you test the original main_led_blink.c example from the PDK? Were you able to trigger interrupts in both WKUP and Main domains?
Interesting that with bedugger I see the interrupt happening in the GPIOMUX_INTRTR0 registers, but Its not getting to my mcu2_1 core somehow. Maybe the interrupt routers connections are wrong.
The register data looks correct. Can you provide the register dump for the GPIOMUX_INTRTR0 register and GPIO registers such as: GPIO_INTSTAT45, GPIO_OUT_DATA45, GPIO_DIR45, and GPIO_IN_DATA45?
Thanks,
Neehar
Yes, I have configured the callback function on that case just like in the original example, but It hasn't worked.
Here are the registers you asked for (I am pressing the button at the moment, so pin 71 is high):
Hi,
Have you tested the original GPIO LED blink example from the PDK? Do these tests pass?
Thanks,
Neehar
The original example is working with pin GPIO1_6 output interrupt. It uses CSL_GPIO1_BASE. But I want to use GPIO0_71 with CSL_GPIO0_BASE, and I can't find the difference that I am missing.
Hi,
Thanks for this information. The register dump looks correct.
I will look into this further and get back to you.
Thanks,
Neehar
Hi,
Even the GPIOMUX_INTRTR0 register looks correct?
I cannot tell as this register is empty in the register dump you sent. Do you know which output is used from the GPIO mux router?
Thanks,
Neehar
According to the datasheet its on GPIOMUX_INTRTR0_OUTP[31:16] somewhere If I understood it right, but don't know where exactly. Where can I find this registers in CCS debugging?
Hi,
Where do you see this on the datasheet? I could not seem to find it.
When we say GPIOMUX_INTRTR0_OUTP[31:16] it is not referring to a register. Instead, it means out of the 64 output interrupts from the GPIOMUX Interrupt Router, GPIOMUX_INTRTR0_OUTP_16 through GPIOMUX_INTRTR0_OUTP_31 are routed to the R5 cores. Please take a look at this diagram of WKUP_GPIOMUX_INTRTR0 as an example:
Thanks,
Neehar
So what register should I check you or what is the next step? Do you have any suggestion why GPIO0_71 is not working?
Hi,
Have you tested building and running on a different core? Such as an MC R5 as MCU1_0?
Thanks,
Neehar
Hi,
Can you test if the GPIO_socConfigIntrPath API return value passes?
Thanks,
Neehar
Through some further debugging it seems like "Sciclient_rmIrqFindRoute()" returns "-1" after search_detph = 3.
Hi,
Thanks for this information, let me look into this further and get back to you tomorrow.
Thanks,
Neehar
Hi,
Can you provide the values for rmIrqReq struct parameter when passed to Sciclient_rmIrqSet()?
Thanks,
Neehar
I was on a holiday sorry for late response.
I have debugged the problem further. I think I am very close to the solution. I think the critical parameter is the "d_irq" when I am calling the "Sciclient_rmIrqFindRoute()". I have copied the parameters from the original calling (which I have get from debugging). You can see them on my code.
I have tried all possible "d_irq" values with a "for" loop, and I watched where does the function returns without error. There was 4 option which returned without (-1): 188, 189, 190 and 191. The original value was 192.
I was curious where does the 192 comes from. I found that the values gets determined in the "GPIO_socConfigIntrPath()" function.
The function "GPIO_socGetIrqRange()" gives the value 188 to "irq_range_start". Then "dst_host_irq" gets the value 192 from "dst_host_irq = irq_range_start + bankNum = 188 + 4", since bankNum is (int) 71/16 = 4.
This value goes to "rmIrqReq.dst_host_irq", which goes to "Sciclient_rmIrqSet()" function. This function calls the "Sciclient_rmIrqFindRoute()" function which I have inspected.
As you can see in my code (line 613), I have hardcoded "dst_host_irq" with a good value: 188. With this the interrupt is working perfectly. I press the button, then the interrupt occurs. So I think there is some structural error with the sciclient. Can you confirm that? Otherwise can you help me what am I misunderstanding here?
Hello,
Our assigned expert is currently out of office. Please expect a delay in response.
Thanks,
Sarabesh S.
Hi,
Are there any updates since the last post? Is the current status the issue with dst_host_irq value within the GPIO_socConfigIntrPath() sciclient API?
Thanks,
Neehar
Yes its the latest update. I couldn't get much deeper than that, because its a bit complicated how the SCI server assembles the interrupt path through the int-routers.
You can see my latest debugging experiences in the message from Oct 29. There were the parameters you have asked for before, I coped them to my testing code based on the debugger. I could validate most of the values from macros and documentations, but "dst_host_irq" was one I was not sure about how It gets the value 192. So that is why I started to try other values with a for cycle. Maybe not this is the parameter which causes the issue.
Hi,
Have you made any changes to the default Boardcfg /drv/sciclient/soc/V1/sciclient_defaultBoardcfg.c?
If not, the src and dest irq indexes will follow the default sciclient board cfg given here.
Thanks,
Neehar
Hi,
I haven't changed that file. Did you check with your environment and reproduce my configurations? In your case what parameters have been passed to Sciclient_rmIrqSet()? If everything works fine for you, can we find the exact point of the missmatch?
Thanks,
Zsombor