Common Runtime Issues#

This section highlights frequently encountered GPIO-related runtime issues in SiWG917-based designs.

For each issue, possible root causes, debugging procedures, and preventive measures are provided to assist in efficient problem identification and resolution.

Pin Multiplexing (Pin-Mux) Conflicts: Peripheral Drivers Overwriting GPIO Configuration#

Root Cause#

GPIOs on SiWG917 are multiplexed with peripheral functions such as Universal Asynchronous Receiver/Transmitter (UART), Serial Peripheral Interface (SPI), Inter-Integrated Circuit (I²C), and Pulse-Width Modulation (PWM).
When a peripheral is initialized, its driver may reconfigure the shared GPIO to the peripheral function, overwriting any prior GPIO configuration.

Debugging Steps#

1. Review the pin multiplexing table in the hardware reference or device data sheet.

2. Verify that the GPIO is not reserved by another peripheral driver.

3. Check initialization order — ensure sl_gpio_set_configuration() is called after all peripheral initializations if GPIO control is required.

4. Use debug logs or read GPIO configuration using GET configuration APIs present in sl_si91x_driver_gpio.c.

Prevention#

• Avoid assigning GPIOs that overlap with active peripheral functions. Use the PIN Tool in Simplicity Studio to allocate pin sets appropriately and prevent functional conflicts.

• If shared use is unavoidable:

  • Explicitly restore GPIO mode after peripheral configuration.

  • Maintain a centralized pin-mux configuration table to prevent accidental overwrites.

GPIO Output Not Observed#

Symptom#

Certain GPIO outputs (e.g., GPIO_12, GPIO_15) do not show expected voltage changes.

Possible Causes#

• Incorrect pin multiplexing (PAD configuration).

• GPIO configured as input or left in Hi-Z state.

• Insufficient drive strength for the connected load.

• Pin conflict with another module or interface (e.g., UART, JTAG).

• GPIOs are not reinitialized after wakeup from the SLEEP states

• The TRACE from the IC to the test point is left open

Debugging Checklist#

1. Verify GPIO direction (OUTPUT mode) using the sl_si91x_gpio_driver_get_pin_direction API or register dump.

2. Confirm pin multiplexing is set to GPIO mode (not a peripheral function).

3. Check drive strength setting (2 / 4 / 8 / 12 mA) to ensure adequate current.

4. Inspect board routing. Verify no hardware short, pull, or conflict exists.

5. Measure pin voltage using an oscilloscope or logic analyzer to confirm signal transitions.

Spikes During Boot-Up (Pre-Configuration)#

Root Cause#

• GPIOs may momentarily toggle or float during boot-up as per the default state mentioned in the Datasheet.

• The Boot ROM may temporarily reassign certain pins (e.g., UART, ISP, or JTAG) before application control takes over.

Default Reset State#

• Not all GPIOs default to input (Hi-Z). Refer to the data sheet for the default state of the GPIOs.

• Internal pull-ups/pull-downs may be inactive during early boot, allowing floating states or transient glitches.

Workarounds#

• Use external pull-up/pull-down resistors on critical control lines (e.g., reset, enable) as per the required default state of the GPIOs .

• Initialize GPIO configurations early in system startup to stabilize outputs quickly.

• For safety-critical signals, use hardware gating until firmware control is established.

Multiple Wake-Up Interrupts When Button is Held#

Root Cause#

• A prolonged button press can cause the system to register multiple interrupt events, as the signal remains in an active state for an extended duration.

Debugging and Mitigation#

1. Use hardware debounce circuits or software filtering to suppress bounce effects.

2. Implement a debounce timer (e.g., ignore events for 50–200 ms after first detection).

Best Practices#

• Mask the interrupt for a particular duration to avoid multiple interrupts.

• Configure mechanical button inputs with internal pull-ups for improved noise immunity.

• Clear interrupt flags promptly after servicing the interrupt.

Leakage Current Issues#

Root Cause#

• Improperly terminated GPIOs can cause leakage currents.

• Internal pull-up/pull-down resistors may not match external circuitry biasing, creating unwanted current paths.

Common Causes#

• Mismatched pull resistor configurations (internal vs. external).

Debug and Mitigation Techniques#

1. Refer to the data sheet for default state of GPIO during ACTIVE and SLEEP.

2. It is recommended to keep unused GPIOs in a floating state to reduce power consumption.

3. Use sl_si91x_gpio_driver_select_pad_driver_disable_state() to define pin states during disable or low-power conditions.

4. Measure leakage using a precision ammeter during deep-sleep entry/exit tests.

5. Minimize external leakage by using high-value pull-up or pull-down resistors (>100 kΩ).

Tip:
Always review GPIO configurations for low-power modes. Improper pad or pull settings are among the most common sources of unexpected power drain in ultra-low-power systems.

Summary of Common Issues and Fixes#