DEBUG PROBES
Your debugger belongs on the same timeline as everything else.
Scryglass treats a USB debug probe as a first-class instrument, next to its power, GPIO and bus channels. Plug one in and it's found. Flash, halt, step, breakpoint, stream logs — without assembling a debug toolchain to do it.
NOTHING ELSE TO INSTALL
Press F5. That's the setup.
A debug adapter is built into Scryglass, so Visual Studio Code talks to your target through the app. One tool speaks to the probe instead of a stack of them that all have to agree.
Describe the target once in your editor's launch configuration and you have source-level debugging: breakpoints, step over and into, call stacks with source locations, locals, and CPU registers. A launch can flash the firmware first, with progress reported as it goes.
ONE TIMELINE
Firmware logs, next to the current trace.
Log output from the target arrives as an ordinary Scryglass channel. That means it gets everything a channel gets: a place on the timeline, text search, a terminal widget, and the ability to fire a recipe.
So the question you actually have — what was the code doing when the current spiked? — is one scroll, not two tools and a stopwatch. Your logs and your measurements share a clock because they were captured against one.
Or stay in the app
Every probe also gets an interactive debug shell inside Scryglass, for when opening an IDE is more ceremony than the question deserves. Halt, resume, reset, single-step. Dump the registers in the architecture's own order. Read and write memory. Add and clear hardware breakpoints.
Flashing handles the formats these targets need, with optional read-back verify and full chip erase — including the unlock path for parts that ship read-protected.
Debugging you can automate
Recipes can watch debug state and drive the core, the same way they drive a power rail or a GPIO. Halt the MCU the moment current exceeds a threshold. Dump the registers when the log prints FAULT. Reset and re-arm, then keep waiting.
Which means the intermittent fault you've been trying to catch by staring at it can be caught by something that doesn't blink. Halt, resume, reset, memory reads and register dumps are all recipe actions.
It tells you when the chip isn't running your build
Before it trusts a breakpoint, Scryglass compares the code at that address on the chip against the binary you're debugging, byte for byte. If they differ, it says so.
That's the lost afternoon where the breakpoint never hits and the flash never took, caught in the first second instead of the third hour. It warns; it doesn't block. You may well have a reason.
Built for a real bench, not a demo
Benches are hostile. You press the reset button mid-session; a probe wedges; the chip's USB port disappears for a moment after a flash. None of that should end your session, and none of it does.
- You press RST
- A supported workflow, not an accident. Hardware breakpoints re-arm themselves in about a second, and the console says so.
- A probe wedges
- Scryglass re-attaches on its own if the probe is still there. If you've actually unplugged it, it unloads cleanly and picks it up again when you plug it back in.
- USB re-enumerates
- The port vanishing after a flash is expected on ESP targets. It's detected and bridged without you noticing.
More than one target at a time
Connect several probes and each one is named and served separately — so a gateway and the node it talks to can be debugged in the same session, with both sets of logs on the same timeline as the traffic between them.
An ESP32 board on its native USB port counts twice, too: it appears as a debug probe and a UART console at the same time, from one cable.
- MODERN ESP32
- No probe at all — just a USB cable.
Included from Maker upwards.
Probe support, flashing and firmware logs are in every paid tier — not an add-on.