GPIO Interrupt not pad muxing automatically on HummingBoard

[me1]

Hi there,

I'm following the Windows IoT team's firmware porting guide to bring up new firmware for the HummingBoard Edge and I've discovered that for some reason the pins I've tried using (66 & 65 in this case) wouldn't come up at GPIO pins when Windows IoT Core booted. I needed to add the following code to u-boot to have the pin appear as GPIO:

#define GPIO_PAD_CTRL \
(PAD_CTL_HYS | PAD_CTL_SPEED_MED | PAD_CTL_DSE_40ohm)

// Sets the EIM_DA1 pad on the SoC to behave as GPIO bank 3 pin 1 with properties we specified in GPIO_PAD_CTRL above
static iomux_v3_cfg_t const accelerometer[] = {
IOMUX_PADS(PAD_EIM_DA1__GPIO3_IO01 | MUX_PAD_CTRL(GPIO_PAD_CTRL)),
};

static void setup_iomux_accel(void)
{
SETUP_IOMUX_PADS(accelerometer);
}

and then call setup_iomux_accel() from board_init().

Is this expected? I ask because I would have expected the pin to be initialized as a GPIO pin without that (defined as GPIOInt in ACPI and requested as an Interrupt in the driver).

Thanks,

Tony Goodhew

The Schnauzer Group LLC

[henrybeberman]

Hi Tony,

What is happening here is the GpioClx driver (inbox in Windows) is servicing your application's request to enable an interrupt resource and it requests the interrupt successfully from the GPIO Controller Driver (imxgpio.sys provided in BSP). The GPIO Controller Driver provides the interrupt resource connected to the pin correctly, but it never makes sure that the pin's function is muxed to be a GPIO input, it just leaves the pin function in the default configuration. This is why you observe correct behavior when the pin is already set to the GPIO function by U-Boot.

My recommendation is for NXP to update the GPIO Controller Driver to explicitly change the pin's function configuration to GPIO whenever it's creating a new interrupt resource, then change the pin's function configuration back to the default when the resource is released. The GPIO Controller Driver is already responsible for pin function configuration, so it should be a very localized fix.

Thanks,

Henry

[igorpadykov]

Hi Tony

> I needed to add the following code to u-boot to have the pin appear as GPIO

>.. I would have expected the pin to be initialized as a GPIO pin without that

right, as not all pins after reset are configured as gpios according to

Table 96. 21 x 21 mm Functional Contact Assignments

i.MX 6Dual/6Quad Applications Processors for Consumer Products - Data Sheet

Best regards
igor
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------