Using an LED Loop to Verify Your Toolchain Is Actually Flashing the Hardware

Have you ever spent hours debugging firmware that should be running, only to discover you never actually flashed the board? Your toolchain just failed silently as flashing broke.

The fastest way to verify your entire toolchain pipeline (IDE -> compiler -> linker -> programmer -> microcontroller) is a simple LED loop. It shows you a clear physical signal that your code executed on the silicon, not just in your build logs.

In this guide, you’ll implement a minimal LED loop on the Texas Instruments CC2340 series and Nordic Semiconductor 54 L series development boards.

The goal is not just to blink an LED, but to verify:

• Flashing works
• Reset vector executes
• You correctly configured the GPIO peripheral clocks and pins
• Your debug/programming connection is valid

Once this loop works, you have a known-good baseline for all future firmware development.

Why Use an LED Loop

UART logs, RTT consoles, and debugger breakpoints all depend on extra subsystems. If any of those fail, you will see indications that something went wrong, but nothing to help you identify the root cause.

An LED loop clears things up because it only depends on:

• CPU execution
• GPIO peripheral
• Board wiring

That makes it the simplest and most reliable hardware verification test.

Both the TI CC2340R5 LaunchPad and Nordic nRF54L15 development boards include on-board LEDs connected to GPIO pins, so you can use them without external wiring.

TI CC2340R5: Minimal LED Loop

The SimpleLink SDK for the TI CC2340R5 LaunchPad already includes button/LED examples, which you can immediately use. However, writing a custom program to blink your LED removes abstraction layers to prove your toolchain works end-to-end in the simplest way possible.

Step 1: Enable the Green LED

1. In your project’s SysConfig, create a GPIO instance
2. In the Use Hardware field, select LaunchPad LED Green

Now you’ve configured your project to use the green LED on your development board.

Step 2: Write the LED Loop

Add the following LED loop code to your main application file:

#include <ti/drivers/GPIO.h>	// TI GPIO drive API
#include <ti/drivers/Board.h>	// Board initialization
#include <unistd.h>   		    // for sleep/usleep

#define LED_PIN 15   		    // Green LED (DIO15) on the CC2340R5 board

int main(void)
{
    // Initialize board-level drivers
    Board_init();

    // Initialize GPIO driver module
    GPIO_init();

    // Configure the LED pin as a standard output that you can toggle, with LED off as the initial state
    GPIO_setConfig(LED_PIN, GPIO_CFG_OUT_STD | GPIO_CFG_OUT_LOW);

    while (1)
    {
        // Toggle the LED state
        GPIO_toggle(LED_PIN);

        // Delay 250 ms between toggles
        // Creates a blink rate of 1 Hz (LED blinks every second)
        usleep(250000);
    }
}

Step 3: Watch the LED Blink

Build and flash your firmware onto the board. You should see the green LED on your board blink every second.

Nordic nRF54L15: Blinky Loop

The nRF Connect SDK already includes a sample LED loop called Blinky. You can use it as-is to prove your toolchain works end-to-end on your Nordic nRF54L15 board.

In nRF Connect, load the Blinky application from samples/basic/blinky. Add the appropriate build configuration, then build and flash this firmware onto your board. Once that completes, you should see LED0 on your board blink green every second.

Common Issues

Flashing Succeeded, But Old Firmware Persists

This problem can happen because of an incomplete erase, wrong flash offset, or a bootloader redirecting execution.

Symptom: LED pattern unchanged.

Fix: Perform a full chip erase before flashing.

Debugger Connected but Programming Never Occurs

This problem can happen because of improper device protection, reset state, or power configuration settings.

Symptom: Build and flash succeeds, but no LED activity is present.

Fix: Power-cycle the board, press RESET before flashing, or unlock the device if needed. For the Nordic nRF54L15, you may even have to re-enable power to the LEDs.

Wrong Board Target

This problem can happen when you build your firmware for the wrong board type (e.g. building for nRF52840 on the nRF54L15 board).

Symptom: Flash succeeds, CPU never runs.

Fix: Correct the board target in your project.

Wrapping Up

When the LED loop runs, you confirm every stage of embedded delivery:

If your LED does not blink, the failure almost always lies in flashing or configuration, not firmware logic. Common problems include old firmware still present in flash, the debugger connecting but not programming, or the build using the wrong board target. A full chip erase, board target check, or power/debug connection reset usually gets your board working again.

Once the LED loop runs reliably, you have proven your toolchain and hardware path works properly end-to-end. That baseline lets you move toward complete system bring-up with confidence: add UART output, test button interrupts, enable BLE advertising, or integrate sensors. Each step builds on a known-working foundation rather than guesswork.

For Hubble workflows, where you may frequently switch SDKs, boards, and PCs, this one-minute LED verification prevents hours of false debugging. Whenever you install a new toolchain, update firmware tools, or connect new hardware, run the LED loop first. If it blinks, your firmware truly runs. If not, fix the problem before touching application code.

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