Debugging Preparation

[thestumbler]

A couple of weeks back, I attempted to run some non-trivial code on two cores. Despite my best efforts, it would not work, with the second core crashing / freezing. Reading the issues here and elsewhere, it looked like I wasn't the only one, and that I was going to need to debug the problem. I ordered a Pi Debug probe for this future debugging effort, and in the meantime I refactored by code to work on one core. I knew it was possible to run on one core, but the timing was quite tricky.

The debugger should arrive soon, and I'll have time for this in a week or so. What are some good references to review in the meantime? I'm generally comfortable debugging STM32F4 families with either STLink-based or BMP/OpenOCD tools.

-Chris

[earlephilhower]

The method here is plain GDB. If you've used it for the STM32, it's the same. You have some number of HW breakpoints, can single step, etc. for multicore there is also the thread command to swap between the cores. Things like USB and I/O will probably fail in the stoped state, but that's not unique to this chip.

[thestumbler]

I'd like to follow up on this, because someone else might get caught in the same trap I did.

Without the debugger, all I knew was my application froze and I had no idea why. I finally got around to setting up the debugger using the RPi Debug Probe. Some points I ran into trying to setup the debugger...

(1) If you are content to use the Arduino IDE v2, you don't need to install anything (as far as I could tell). If, like me, you had held off moving to IDE v2 because there was no VSCode integration, that is not an excuse anymore -- Microsoft has pulled the Arduino extension from the VSCode package store.

(2) If you want to install OpenOCD separately, note that RPi has their own fork / flavor of OpenOCD that works out of the box. I was able to get my own installation of OpenOCD and GDB running from the command line, should the need arise. Do not misread the RPi Debug Probe instructions, as I did, and install from the OpenOCD repository. I wasted almost a day trying to get that to compile and work. Disclaimer: if you really know OpenOCD, it might be a trivial task. Disclaimer 2: I was running this on MacOS, so I wouldn't be surprised if doing it on Linux or Windows was easier.

If you've used the debugger in VSCode before, the one in Arduino IDE v2 looks and behaves very much the same. Almost no learning curve to become useful with the tool.

Back to my firmware problem... once I fired up the debugger, I found the problem in 30 seconds. Way back in the start of this project, I was curious about using the BOOT button as a general purpose user button. I found some code on the RPi GitHub, stuck it in my code, and promptly forgot about it. Upon revisiting the notes in that function, I'm not surprised that it threw a wrench in my attempt at dual core processing:

// Picoboard has a button attached to the flash CS pin, which the bootrom
// checks, and jumps straight to the USB bootcode if the button is pressed
// (pulling flash CS low). We can check this pin in by jumping to some code in
// SRAM (so that the XIP interface is not required), floating the flash CS
// pin, and observing whether it is pulled low.
//
// This doesn't work if others are trying to access flash at the same time,
// e.g. XIP streamer, or the other core.

Finally, in case anyone is curious, I put 2 each I2S receiver classes in core 1 (2 pair of stereo PCM1802 ADCs, total of four channels). I'm pulling in audio in 10 ms buffer and doing some simple processing on each buffer. The connection between the audio processing and my main code is only four 32-bit integers (one per channel), one direction only, which lessens concerns with IPC. In my case, the total processing takes only about 2.5 ms out of that 10 ms time slice, so conceivably I could ramp that up to at least 8 channels, maybe 12 or 16 if I didn't want any headroom. YMMV

[earlephilhower]

Great update. A couple notes:
. We include a precompiled RPi-patched OpenOCD for all systems, check your tools folder. The TCL scripts are in lib/rp{2040,2350}/picoprobe_cmsis_dap.tcl
. If you use the core's multiprocessing stuff (setup1/loop1), then using BOOTSEL will read that pin while safely freezing the other core in RAM.

[thestumbler]

Both of those are good to note. I'm not even using the button for now, I was just curious at the start -- when you're blinking an LED to check the build and upload process is all good. Glad to know this button macro(?) is available.