Categories
Computing

Day 6: Debugging Yarg

For Day 1, go here. The series is tagged advent-2025.

As I discovered previously, there seems to be a bug somewhere in the Yarg interrupt handling. While the box contents are basically the same as my ‘hello_button’ example, the circuit from yesterday only handles one interrupt before halting for some reason.

Debugging C on the Pico (which is how Yarg is implemented on the device) can be achieved with the Raspberry Pi Debug Probe (around £12). This connects to the Pico being debugged, and allows GDB (via open OCD) to step through code, set breakpoints and so on. I use it within VSCode, which gives me some convenient views of the RP2040 registers and integration with the rest of the Yarg project.

Advent Box 3 (on the left), and a Debug Probe (on the right in the small plastic enclosure).

The Debug Probe is effectively a specialised Pico, with the same RP2040 microcontroller, and dedicated connectors – USB to the host, and two serial ports to connect to the device being debugged.

One serial port is a standard UART connection needing TX, RX and Ground pins. Using this in preference to the Pico’s support for UART over USB eliminates the start-up time for the USB connection. The USB connection can be negotiated with the debug probe, and the UART connection to the device can connect on demand, practically instantly.

The other serial port is the ARM SWD port (Data, Clock, Ground), which is exposed via Open-OCD to the host to provide conventional debug services.

The Debug Probe comes with some useful connectors, and we’ll use two to connect to the Pico H the Advent Calendar came with:

Debug Probe connected to Pico UART0 and SWD

Notice how the Pico USB no longer needs to be connected, although you do need to supply power to the Pico somehow. I often connect the USB, and then choose in software which serial connection to debug with, and which to use for flashing.

With this setup I can use the VSCode debugger interface to start Yarg and step through code.

For the future, the same debug probe firmware can be run on a standard Pico, converting it into a dedicated debugger. I imagine I will use this when I want to build up a dedicated hardware test harness. I hope to tackle that sometime in the new year!

Categories
Computing

Day 5, Box 3 Part 1 – a bug

For Day 1, go here. The series is tagged advent-2025.

I don’t want to exactly copy the code from the Micropython calendar, because part of the point of Yarg is that it makes using an event-loop style of programming much easier.

For Box 3, two buttons are supplied, and that sounds a lot like my button.ya test code. It’s lightly edited, so that the GPIO lines are the same as ThePiHut suggest:

https://github.com/jhmcaleely/advent-2025/tree/main/box3

Running it today, on 0.2.1, it responds to the first interrupt only, and then halts with a fatal exception. That’s a puzzle, as the test code was working when I made the release!

So I will break out the debugger tomorrow, and see what is going wrong.

Categories
Computing

Day 4, Box 2 – flashing LED

For Day 1, go here. The series is tagged advent-2025.

For Box 2 in the calendar, we get an LED, a resistor and a pair of jumper leads. We can connect those up:

And type these lines into the REPL:

place struct { uint32@0x014 gpio_out_set; uint32@0x024 gpio_oe_set; } @xd0000000 sio_hw;

place struct { struct { uint32@0x4 ctrl; }[30] gpio; } @x40014000 io_bank0;

const block_led = 0d14;

const gpio_field = 0x1 << block_led;

poke io_bank0.gpio[block_led].ctrl, 0d5;

poke sio_hw.gpio_oe_set, gpio_field;

poke sio_hw.gpio_out_set, gpio_field;

This is almost the same as hello_led, but I have removed a couple of the constant definitions, to minimise typing.

Of course, typing line-by-line will get old quick, so we need a way to load a whole Yarg file at once. That’s the job of hostyarg, which currently requires go to be installed. This tool will take an existing Yarg uf2 file and add a Yarg file to it.

So head over to the go website, and install go for your O/S. Follow the release README to then install hostyarg.

Once you have that, you’ll want to flash an LED like the MicroPython folks. Let’s stop poking raw registers for GPIO, and use a library. In fact we’ll use two – one for GPIO (called, ‘gpio’!), and one for a sleep function (‘timer’).

Here’s the file (flash.ya) in full, and it’s in this GitHub repo:

import("gpio");
import("timer");

const blocky_LED = 0d14;
gpio_init(blocky_LED);
gpio_set_direction(blocky_LED, GPIO_OUT);

var n = 4;

while (n > 0) {
    gpio_put(blocky_LED, !gpio_get(blocky_LED));
    sleep_ms(500);
    n = n - 1;
}

Yarg files are plain text (officially utf8, but ascii will be fine for this example).

We need to use hostyarg to add it to the uf2 from the release. First we make a copy (I’ll assume you’re using the repo’s file structure), and then add the file:

% cd box2
% cp ../yarg-lang-pico-0.2.1/yarg-lang-pico-0.2.0.uf2 box2.uf2

% hostyarg addfile -fs box2.uf2 -add flash.ya

box2.uf2 now can be flashed onto the pico in the usual way. Once that boots up, and presents the > prompt (maybe press return to get it), use the import function to run it:

> import("flash");

And we see the LED flash! That’s it for box2.

You’ll see a box2.uf2 in the repo if you can’t get hostyarg working. If you want to edit the flash.ya file, you’ll need to copy the base uf2 and use addle each time. There’s no way to edit an existing file at this time.