PROCESSOR-SDK-J784S4: GPIO API usage

Milos Reljin

Tool/software:

Hello everyone,

I'm trying to test external watchdog by using GPIO API on TDA4.
Here's the relevant code which I based off of the code I've seen in other thread here on the forum:

#define PADCONFIG_34      0x0011C088
#define WKUP_PADCONFIG_23 0x4301C05C
#define WKUP_PADCONFIG_41 0x4301C0A4

#define MCU_WDT_WDI_PIN   (38U)
#define MCU_WDT_WDO_PIN   (34U)

#define SYS_MCU_PWRDN_PIN (55U)


static void watchdog_isr(void)
{
    App_ConsolePrintf("Watchdog triggered!\n");

    // Make rising edge on SYS_MCU_PWRDN pin
    GPIOPinWrite_v0(CSL_WKUP_GPIO0_BASE, SYS_MCU_PWRDN_PIN, GPIO_PIN_LOW);
    GPIOPinWrite_v0(CSL_WKUP_GPIO0_BASE, SYS_MCU_PWRDN_PIN, GPIO_PIN_HIGH);
}

GPIO_PinConfig gpioPinConfigs[] = {
    GPIO_DEVICE_CONFIG(0, MCU_WDT_WDO_PIN) |
    GPIO_CFG_IN_INT_FALLING | GPIO_CFG_INPUT,

    GPIO_DEVICE_CONFIG(0, MCU_WDT_WDI_PIN) |
    GPIO_CFG_OUTPUT,

    GPIO_DEVICE_CONFIG(0, SYS_MCU_PWRDN_PIN) |
    GPIO_CFG_OUTPUT
};

GPIO_CallbackFxn callbacks[] = {
    watchdog_isr,
    NULL,
    NULL
};

GPIO_v0_Config GPIO_v0_config = {
    gpioPinConfigs,
    callbacks,
    sizeof(gpioPinConfigs) / sizeof(gpioPinConfigs[0]),
    sizeof(callbacks) / sizeof(callbacks[0]),
    ~0
};

void AppGPIOPadConfig()
{
    *(uint32_t*)PADCONFIG_34      = 0x00060007;
    *(uint32_t*)WKUP_PADCONFIG_23 = 0x00010007;
    *(uint32_t*)WKUP_PADCONFIG_41 = 0x00010007;
}


///////////////////////////////////////////////////////////

    GPIO_v0_HwAttrs gpio_cfg;
    GPIO_socGetInitCfg(0, &gpio_cfg);
    gpio_cfg.baseAddr = CSL_WKUP_GPIO0_BASE;
    (gpio_cfg.intCfg[0]).intcMuxNum = INVALID_INTC_MUX_NUM;
    (gpio_cfg.intCfg[0]).intcMuxInEvent = 0;
    (gpio_cfg.intCfg[0]).intcMuxOutEvent = 0;
    GPIO_socSetInitCfg(0, &gpio_cfg);

    GPIO_init();

    //GPIO_setCallback(0, watchdog_isr);
    GPIO_enableInt(0);

    AppGPIOPadConfig();

    GPIOSetDirMode_v0(CSL_WKUP_GPIO0_BASE, MCU_WDT_WDI_PIN, GPIO_DIRECTION_OUTPUT);
    GPIOPinWrite_v0(CSL_WKUP_GPIO0_BASE, MCU_WDT_WDI_PIN, GPIO_PIN_HIGH);

    //GPIOSetDirMode_v0(CSL_WKUP_GPIO0_BASE, MCU_WDT_WDO_PIN, GPIO_DIRECTION_INPUT);

    GPIOSetDirMode_v0(CSL_WKUP_GPIO0_BASE, SYS_MCU_PWRDN_PIN, GPIO_DIRECTION_OUTPUT);

    // Attempt to activate callback manually
    GPIO_toggle(0);
    Osal_delay(20);
    GPIO_toggle(0);

    for (uint32_t i = 0; i < 20; i++)
    {
        App_ConsolePrintf("\nNotifying watchdog...\n");

        // Make a falling edge on WDI and assert it back
        GPIOPinWrite_v0(CSL_WKUP_GPIO0_BASE, MCU_WDT_WDI_PIN, GPIO_PIN_LOW);
        GPIOPinWrite_v0(CSL_WKUP_GPIO0_BASE, MCU_WDT_WDI_PIN, GPIO_PIN_HIGH);

        Osal_delay(1000);
    }

    App_ConsolePrintf("\nStopped notifications. Waiting for watchog to trigger.\n");

    GPIOPinWrite_v0(CSL_WKUP_GPIO0_BASE, SYS_MCU_PWRDN_PIN, GPIO_PIN_LOW);
    Osal_delay(50);
    GPIOPinWrite_v0(CSL_WKUP_GPIO0_BASE, SYS_MCU_PWRDN_PIN, GPIO_PIN_HIGH);

The issue is that watchdog_isr callback never gets called even when using GPIO_toggle to manually trigger it.
I also took a look at SYS_MCU_PWRD pin with oscilloscope and there weren't any changes.
Any help would be appreciated.

6 months ago

0 Neehar Sawant 6 months ago

TI__Mastermind 19290 points

Hi Milos,

A couple things I want to confirm:

I don't see any code toggling or writing to MCU_WDT_WDO_PIN. Where are you doing this to trigger the ISR? Your watchdog_isr is set up for MCU_WDT_WDO_PIN.
Are you using WKUP_GPIO0_34 or GPIO0_34 for MCU_WDT_WDO_PIN? I see you are using the PADCONFIG for GPIO0_34, however, you set the base address to CSL_WKUP_GPIO0_BASE.

Thanks,

Neehar

0 Milos Reljin 6 months ago in reply to Neehar Sawant

Prodigy 50 points

Hi Neehar,

The code for toggling MCU_WDT_WDO_PIN is on lines 77-80:

    // Attempt to activate callback manually
    GPIO_toggle(0);
    Osal_delay(20);
    GPIO_toggle(0);

Thanks for pointing out this discrepancy, indeed this is an error. I am targeting WKUP_GPIO0_34, so I changed the code to use WKUP_PADCONFIG_19 (0x4301C04C).
Unfortunately, even with this fix the IRQ handler doesn't get called.

0 Neehar Sawant 6 months ago in reply to Milos Reljin

TI__Mastermind 19290 points

Hi Milos,

Milos Reljin said:
The code for toggling MCU_WDT_WDO_PIN is on lines 77-80:

Thanks for pointing this out, I completely missed this.

Additionally, when initializing the interrupt configuration, you will want to do so on the pin you are setting up the interrupt for.

For example:

#define MCU_WDT_WDO_PIN   (34U)

GPIO_socGetInitCfg(0, &gpio_cfg);
gpio_cfg.baseAddr = CSL_WKUP_GPIO0_BASE;
(gpio_cfg.intCfg[34]).intcMuxNum = INVALID_INTC_MUX_NUM;
(gpio_cfg.intCfg[34]).intcMuxInEvent = 0;
(gpio_cfg.intCfg[34]).intcMuxOutEvent = 0;
GPIO_socSetInitCfg(0, &gpio_cfg);

Take a look at this FAQ and the GPIO example within the RTOS PDK for more information.

Thanks,

Neehar

0 Milos Reljin 6 months ago in reply to Neehar Sawant

Prodigy 50 points

Thanks Neehar,

I fixed the index in the intCfg structure, but to no avail. I also took a look at the FAQ and I couldn't see what else is wrong.
But it's definitely not related only to interrupts since, as I wrote in my initial message, toggling output GPIO pin doesn't seem to work because I didn't observe the change with oscilloscope. It seems that I'm missing some crucial component for GPIO API but can't figure out what exactly.

0 Neehar Sawant 6 months ago in reply to Milos Reljin

TI__Mastermind 19290 points

Hi Milos,

Let me look into this further and get back to you.

Thanks,

Neehar

0 Neehar Sawant 6 months ago in reply to Neehar Sawant

TI__Mastermind 19290 points

Hi Milos,

Are you missing the Board initialization steps I have outlined below?

Board_initCfg boardCfg;

boardCfg = BOARD_INIT_PINMUX_CONFIG |
    BOARD_INIT_MODULE_CLOCK |
    BOARD_INIT_UART_STDIO;
Board_init(boardCfg);

Do you have issues toggling all the pins provided?

Additionally, you are not required to call GPIOSetDirMode_v0() if you set the direction in the gpioPinConfigs[].

Thanks,

Neehar

0 Milos Reljin 6 months ago in reply to Neehar Sawant

Prodigy 50 points

Hi Neehar,

I do have those flags set during Board_init call. In the meantime, I tried running GPIO_Baremetal_LedBlink_TestApp example application on TI EVA board and it works. However, when I compiled the same app without any changes in the code and ran it on our custom board, interrupt handler never triggered.
Any ideas why this would happen?

Best Regards,
Milos

0 Neehar Sawant 6 months ago in reply to Milos Reljin

TI__Mastermind 19290 points

Hi Milos,

Can you confirm the balls used in the example are not used elsewhere in your custom board design or in another application? These are specifically ball L37 for WKUP_GPIO0_6 and AL32 for GPIO0_11. Do both WKUP and main GPIO unable to be toggled?

Additionally, do you have issues with any of the other GPIO in your application?

Thanks,

Neehar

0 Milos Reljin 6 months ago in reply to Neehar Sawant

Prodigy 50 points

Hi Neehar,

Both of these pins are used as interrupt inputs on our custom board. There are no external pull-ups/pull-downs on these pins - they are connected directly with the components generating the interrupts.

I changed the GPIO_Baremetal_LedBlink_TestApp example so that the while loop which checks for interrupt in MAIN domain comes before the one for WKUP domain and it is triggered. This matches our experience in other attempts to use GPIO: for some reason, we can use GPIOs in MAIN domain but not in WKUP.

0 Neehar Sawant 6 months ago in reply to Milos Reljin

TI__Mastermind 19290 points

Hi Milos,

For WKUP GPIO, can you check the INTSTAT register to see if the interrupt is triggered?

For both WKUP_GPIO0_38 and WKUP_GPIO0_55, the register address for GPIO_INTSTAT23 is 4211 005Ch.

If there is an issue with WKUP GPIO, this may be due to the interrupt routing. First step would be to see if interrupt is triggered. What core are you running this application on? There may not be interrupt lines allocated for this core from the WKUP_GPIOMUX_INTRTR. You would have to allocate these lines in the board config.

Thanks,

Neehar

0 Milos Reljin 6 months ago in reply to Neehar Sawant

Prodigy 50 points

Hi Neehar,

I just checked and GPIO_INTSTAT23 is zero after calling GPIO_troggle and waiting for 5 seconds.
I don't suspect interrupt routing (although I'm not 100% certain) because the GPIO LEDs example shows that same setup on TI EVM and custom board give different results. In both cases nothing else besides the test app is running on the board and in both cases on the same core: MCU1_0.

0 Neehar Sawant 6 months ago in reply to Milos Reljin

TI__Mastermind 19290 points

Hi Milos,

Milos Reljin said:
I don't suspect interrupt routing (although I'm not 100% certain) because the GPIO LEDs example shows that same setup on TI EVM and custom board give different results

Yes good point, it is likely not interrupt routing but I don't think that can be fully ruled out. Can you log and see what is returned by GPIO_socConfigIntrPath()?

Milos Reljin said:
I just checked and GPIO_INTSTAT23 is zero after calling GPIO_troggle and waiting for 5 seconds.

This is good information, let me look deeper to see why it is not updating the INTSTAT.

Thanks,

Neehar

0 Milos Reljin 6 months ago in reply to Neehar Sawant

Prodigy 50 points

Hi Neehar,

I called GPIO_socConfigIntrPath like this:

    GPIO_v0_HwAttrs gpio_cfg;
    GPIO_socGetInitCfg(0, &gpio_cfg);
    gpio_cfg.baseAddr = CSL_WKUP_GPIO0_BASE;
    gpio_cfg.intCfg[34].intcMuxNum = INVALID_INTC_MUX_NUM;
    gpio_cfg.intCfg[34].intcMuxInEvent = 0;
    gpio_cfg.intCfg[34].intcMuxOutEvent = 0;
    GPIO_socSetInitCfg(0, &gpio_cfg);

    int32_t ret = GPIO_socConfigIntrPath(0, 34, &gpio_cfg, true);
    App_ConsolePrintf("GPIO_socConfigIntrPath returned: %d\n", ret);

Return value is zero.

EDIT: I tried toggling these pins from u-boot with gpio set/clear command. I got warning that pin level is 0 when I try to set it to 1. It seems as if writing to these is somehow locked. But then I tried to set WKUP_GPIO0_4 the same way and this worked! Afterwards I tried setting pin 4 to 1 from my app and it also worked.
So changing state to the three pins I need is prevented, but for some others it works fine.

EDIT 2: I figured out that we have problem on the board - the interrupt line which is connected to WKUP_GPIO0_34 should be active on falling edge and has a pull-up on it. When I touch it with oscilloscope probe, it temporarily brings the signal low and activates the interrupt handler. So it is not (entirely) SW issue, but I still don't know why the interrupt handler won't trigger with GPIO_toggle call..
Also, the problem with controlling output pin is completely outside TDA4. I measured close to the pin and it actually behaves as it should but somewhere on the board a resistor was removed, creating open circuit, and that was the reason why I didn't notice the signal change when I previously measured it in different place.

0 Neehar Sawant 4 months ago in reply to Milos Reljin

TI__Mastermind 19290 points

Hi Milos,

Sorry for the delay as I have had very low bandwidth, is this issue still open?

Were you able to work around your hardware issues?

Thanks,

Neehar

0 Neehar Sawant 3 months ago in reply to Neehar Sawant

TI__Mastermind 19290 points

Hi Milos,

Following up, is this issue still open?

Thanks,

Neehar

0 Milena Milosevic 2 months ago in reply to Neehar Sawant

Expert 1115 points

Hi Neehar,

We can close this issue.

Regards,

Milena

Processors

Processors forum

PROCESSOR-SDK-J784S4: GPIO API usage