AnsweredAssumed Answered

GPIO Interrupt not pad muxing automatically on HummingBoard

Question asked by Tony Goodhew on Aug 23, 2019
Latest reply on Sep 10, 2019 by Henry Beberman

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

Outcomes