Debugging MicroPython has, for most people, meant print(). You scatter prints through the code, watch the serial console, and reason backwards. It works, in the way that reading a book through a keyhole works.
The proper solution has always existed — attach a hardware debug probe over SWD or JTAG and step through code — but it means extra hardware, extra wiring, and a toolchain most people building a light sculpture don’t want to learn.
GHI Electronics has released a Visual Studio Code extension that does on-chip source-level debugging over the same USB cable you already program with.
What you get
- Breakpoints that halt execution where you put them
- Stepping through code line by line
- Variable inspection at runtime
- Visual control flow
That’s the standard debugger feature set, applied to Python running on a microcontroller, with no additional hardware.
Support, honestly
Supported: several Raspberry Pi Pico variants, ESP32 chips, and custom-built MicroPython images.
Not uniformly: the Hackaday write-up notes an RP2040 GEEK that accepted the firmware but then produced setup errors, and Linux users reporting similar trouble with ESP32-S3 boards. Building images for unsupported boards means setting up toolchains and dependencies, which is exactly the friction this extension exists to avoid.
Two documented limitations worth knowing before you rely on it:
- It can’t catch exceptions your code already handles. Breakpoints inside exception handlers still work, so there’s a workaround, but automatic break-on-throw won’t fire for caught exceptions.
- Breakpoints halt all threads. For single-threaded sketches this doesn’t matter. For anything with a background task — driving LEDs while reading a sensor, say — stopping everything changes the situation you’re trying to observe.
Why creative coders should care
Microcontroller projects in this field are usually timing-and-state problems: a sensor reads correctly in isolation but not in the loop, an animation stutters every few seconds, a state machine gets stuck in a mode nobody can reproduce. Those are exactly the bugs print-debugging is worst at, because printing changes the timing you’re investigating.
Being able to stop at the moment the state goes wrong and look at every variable collapses an afternoon of guessing into a few minutes. Anyone who works in both desktop and embedded environments knows how much of the difficulty of the embedded side is simply not being able to see.
Pre-built firmware images for supported boards are in the repository, so on a standard Pico or ESP32 this is a ten-minute trial rather than a project.