GPIOs can be set to illegal states

[nseidle]

Following code compiles but pin never outputs High. The reason is the pinMode sets pad 27 to INPUT_PULL which is some sort of illegal state

If you do the following code with pad 28, works great. I think this failure mode is happening on a few different pins.

See file ap3_gpio.cpp. padMode() calls am_hal_gpio_pinconfig, retval is non-zero.

If you simply do a pinMode(27, INPUT); everything works as expected (but without wanted pullups).

void setup() {
Serial.begin(9600);
Serial.println("Test");

pinMode(27, INPUT_PULLUP);
}

void loop() {
if (digitalRead(27) == LOW)
Serial.println("Low");
else
Serial.println("High");
delay(250);
}

[nseidle]

Hmm, this might be a HAL bug.

Page 380 datasheet: All pins should have pull up capability

Inside am_hal_gpio.c we have the following pad mode validity check:

The array is defined higher up as the following:

I may be interpreting things wrong but the code currently errors out on pin 27 even though it's defined as CAP_PUP (indicating pin as PUP capabilities).

Additional question: Why are a large fraction of the pins defined as CAP_RSV when 49 of them should have CAP_PUP according to datasheet? I must be confused somewhere.

[nseidle]

Digging a bit deeper (and for my own notes), g_ui8Bit76Capabilities[] is related to the smaller 1.5k to 24k internal pull up resistors for I2C pins on 0, 1, 5, 6, 8, etc. Not all pins. But all pins have internal weak pull ups.

I think line 435 has two typos:

    else if (bfGpioCfg.ePullup != AM_HAL_GPIO_PIN_PULLUP_WEAK)
    {
        if (g_ui8Bit76Capabilities[ui32Pin] & (CAP_PUP | CAP_PDN) == 0)
        {
            return AM_HAL_GPIO_ERR_PULLUP;
        }

This is a change to the HAL which is unsettling but fixes this issue.

[nseidle]

Ambiq confirmed the HAL bug and will be fixed in next SDK release.