Ask
27

The onboard LED on my board does nothing when I toggle its pin — the classic blink sketch just does not work

New board, and the first thing I tried was blinking the onboard LED. Nothing happens. The pin toggles as far as I can tell — I added serial output and the loop is definitely running — but the LED never lights.

The board does have an onboard LED, clearly visible, and it flashes briefly during upload so it is not dead.

I have tried the built-in LED constant and I have tried the pin number I found in a pinout diagram. Neither does anything.

What am I missing on this board that was not true of the older one I learned on?

4 answers Share
Report

Answering anonymously — a moderator will review it first.

  • @addressable_ana · 11h ago

    Almost certainly this: the onboard LED on your newer board is an addressable RGB LED, not a plain one.

    A plain LED is a diode with a resistor. Drive its pin high and it lights. That is what you learned on and it is why the blink sketch is the first thing anyone runs.

    An addressable LED is a different component entirely — it contains a small controller chip, and it is driven by a serial data protocol on a single wire, not by a voltage level. Toggling the pin high and low sends it noise, which it ignores. It stays dark and nothing is broken. This is why your loop demonstrably runs and nothing happens.

    The flash you see during upload is the bootloader deliberately driving it as a status indicator, which is what confirms the LED itself is fine.

    To drive it you need a library that speaks the protocol. The timing is tight enough that you cannot reasonably bit-bang it by hand; use one of the standard addressable-LED libraries. The pattern is: create an object for one LED on the correct pin, set a colour, call the method that pushes the data out. Three lines.

    Two details that trip people up on these boards:

    Which pin. The addressable LED is usually on a different pin from the plain built-in LED constant, and on several boards that constant is either not defined or points somewhere else entirely. Recent board support packages define a separate constant for the RGB LED's pin — look for that in the board's pin definitions rather than in a generic pinout image, because the images for these boards are frequently wrong or for a different revision.

    Power to the LED. On several designs the RGB LED's supply is gated by another pin that must be driven high before it will light at all. Set the colour perfectly with that pin low and you get nothing. Check the board's schematic or its official example — the vendor's own RGB example will have this in it, and it is the single most common reason the correct-looking code still produces darkness.

    Also worth knowing: brightness. These are very bright at full scale, and full white draws meaningfully more current than a plain indicator LED. Start at a low brightness — both for your eyes and because a board on a marginal supply can brown out when you light it fully white while doing something else.

    If you specifically want a simple blink to prove the board works, most of these boards also have a plain LED somewhere, or you can wire one to any spare pin with a resistor. But the RGB one is what is on the board, and it takes five minutes to drive properly.

    30
    Share
    Reply

    Answering anonymously — a moderator will review it first.

    Report
  • @serial_port_sven · 3d ago

    General principle worth extracting, because it comes up again with displays and sensors: check what kind of component it is before you decide the code is wrong.

    The symptom "my code runs and the hardware does nothing" almost always means the interface is different from the one you assumed — a level where a protocol was expected, the wrong bus, or a device that needs initialising before it responds to anything.

    Serial output proving the loop runs is good practice and it did its job here: it told you the problem is downstream of the code. That is the right first move every time.

    21
    Share
    Reply

    Answering anonymously — a moderator will review it first.

    Report
  • @boot_mode_bea · 15h ago

    Second the pinout-image warning. These board families have many revisions, several manufacturers making near-identical clones, and the diagram you found through an image search is very often for a different one.

    The authoritative source is the board definition in the support package you have installed — the header that defines the pin constants. Those constants are what your code actually compiles against, so if the constant exists there and the diagram disagrees, the diagram is wrong.

    On a board where the constant does not exist at all, that is itself information: it tells you the board package does not think there is a plain built-in LED, which is a strong hint you are on an RGB-only board.

    26
    Share
    Reply

    Answering anonymously — a moderator will review it first.

    Report
  • @local_first_lena · 12h ago

    Worth adding that some boards have both — a plain LED and an addressable one — and only one of them is on the built-in constant.

    So "the constant does nothing" and "there is definitely an LED on the board" can both be true while you look at the wrong LED. Look for two of them before concluding anything; on small boards they are easy to mistake for a power indicator.

    14
    Share
    Reply

    Answering anonymously — a moderator will review it first.

    Report