Mastering GPIO Configuration

In a previous tutorial, you learned how to map physical header pins to logical GPIO numbers. The next challenge is configuring the pin so it behaves correctly in hardware. This is another common problem for firmware developers. Your firmware references the right GPIO, but the pin is misconfigured electrically.

In this guide, you’ll learn how to master GPIO configuration on the Texas Instruments CC2340 series and Nordic Semiconductor 54 L series development boards. Both boards have standard digital pins, but you have to configure them differently. TI uses SysConfig-generated board metadata, while Nordic uses Zephyr devicetree files. Despite their differences, they share a few key layers that you should understand to bring-up a development board from any vendor.

The Four Layers of GPIO Configuration

The only way to get reliable GPIO behavior on both the TI CC2340R5 LaunchPad and Nordic nRF54L15 boards is to verify the following four configuration layers. All of them are directly influenced by your project’s SysConfig or devicetree:

1. Pin ownership You must assign your pin to a GPIO, not a peripheral.

• TI: SysConfig pin assignment
• Nordic: devicetree GPIO controller binding

2. Direction and drive mode You must configure your pin as input or output with the correct drive type.

• TI: SysConfig GPIO mode flags
• Nordic: gpio_pin_configure runtime flags

3. Polarity and default state You must ensure the logical active level in firmware matches the pin’s electrical output.

• TI: SysConfig default/output level
• Nordic: GPIO_ACTIVE_HIGH/LOW devicetree flag

4. Electrical domain and load You must ensure the pin voltage rail and drive capability supports the external circuit.

• TI: 3.3 V pin with limited drive current
• Nordic: selectable GPIO rail (1.8 V - 3.3 V)

When your GPIO fails, diagnose these layers in order. That is the only way to verify your GPIO is functioning correctly on any board.

Mastering GPIO on the TI CC2340R5

On the TI CC2340R5, the SysConfig does far more than simply assign pins. It defines the pin’s electrical behavior at compile time and generates driver configuration tables that the GPIO API uses. Treat your project’s SysConfig as the authoritative source of GPIO behavior.

Before you begin, make sure you have gone through the TI section of the previous tutorial. The steps below build upon the project you created and configured there.

Add the following code to your main application file. Go through the following checkpoints one-by-one, using your current firmware as an example.

int main(void)
{
	// Configure the header pin as a standard output that can be toggled, with off as the initial state
	GPIO_setConfig(CONFIG_GPIO_LED_CONST, GPIO_CFG_OUT_STD | GPIO_CFG_OUT_HIGH);
	while (1) {}
}

Configuration Checkpoints

Pin Ownership

Open the Pins view in your SysConfig and confirm the pin is assigned to the GPIO function. Peripheral functions may silently override GPIO functions if they exist on the same pin.

Direction and Drive Mode

Verify your pin is in Output mode and has the Standard (push-pull) output type. The wrong output mode or type could lead to unexpected pin behavior (e.g. 0 V on the pin when it’s supposed to be 3.3 V)

Polarity and Default State

Build and flash your firmware onto your board. Use a multimeter to verify the voltage across your target GPIO pin is 3.3 V. If you get a different voltage here after passing both previous checkpoints, inspect that your polarity and default state are correct.

Electrical Domain and Load

Measure the voltage across your target pin under load. An easy load to add to your setup is by wiring a resistor and an external LED to your GPIO (see below). Verify the voltage is close to 3.3 V. If it isn’t, your load has exceeded the drive limit of your board and you may need to change your hardware (board or connected devices).

Mastering GPIO on the Nordic nRF54L15

On the Nordic nRF54L15, GPIO configuration is distributed across the devicetree and runtime API. The devicetree establishes pin identity and polarity, while the firmware sets direction and flags. Treat both sources together as one configuration of GPIO behavior.

Before you begin, make sure you have gone through the Nordic section of the previous tutorial. The steps below build upon the project you created and configured there.

Add the following code to your main application file, and build and flash your board. Go through the following checkpoints one-by-one, using your current firmware as an example.

int main(void)
{

    while (1)
    {
	  // Toggle the pin voltage every second
        gpio_pin_toggle_dt(&led);
        k_sleep(K_SECONDS(1));
    }
}

Configuration Checkpoints

Pin Ownership

Verify the devicetree controller (&gpio0, &gpio1) and pin index match the hardware using a multimeter. You should see the voltage toggle between 3.3 V and 0 V every second.

Direction and Drive Mode

If you verified pin ownership using the example above, you actually also verified the pin direction and drive mode, too. Below is a table of other results you may see and the cause of those problems.

Polarity and Default State

Disable the toggle code in your main loop, and build and flash your board again. Verify the voltage across your target GPIO pin is 3.3 V. If you get a different voltage here after passing both previous checkpoints, you probably misconfigured your devicetree.

Electrical Domain and Load

Measure the voltage across your target pin under load. An easy load to add to your setup is by wiring a resistor and an external LED to your GPIO (see below). Verify the voltage is close to 3.3 V. If it isn’t, your load has exceeded the drive limit of your board and you may need to reconfigure your board.

Wrapping Up

Mastering GPIO configuration means understanding how your firmware becomes real pin behavior through a small set of configuration layers. On the TI CC2340R5, SysConfig centralizes those layers into generated board metadata. On the Nordic nRF54L15, devicetree and runtime API share the responsibility. Although the tools differ, both ultimately control the same result: a GPIO pin with configurable ownership, direction, polarity, and electrical domain.

When your GPIO does not behave as expected, check each configuration layer instead of focusing on the vendor tool. This is a much more effective approach to not only solving your problem but also giving you the skills to fix GPIO on any platform. With these techniques, you now know how to make GPIO bring-up fast, reliable, and repeatable across boards.

Ready to connect your devices anywhere on Earth? Get started with Hubble Network for free →