Debugging, datasheets and reliability

Printing has limits: the crash can happen before the print, or the print itself can change the timing. The next tool is the hardware debugger. On Cortex-M chips, the SWD interface needs only 2 signals, SWDIO for data and SWCLK for the clock, plus ground. Nucleo boards include an ST-Link adapter, so you already have one. The Pico exposes its SWD pins but needs a Raspberry Pi Debug Probe (about USD 12) or a second Pico running the debugprobe firmware. The Arduino Uno has no SWD and no debugger; on that board, continue to use prints or borrow a Nucleo for this lesson. With a debugger you can stop the program anywhere, step through it one line at a time, and inspect every variable and register.

Datasheets are long, but they consist mostly of tables. Start with 2 of them. The Absolute Maximum Ratings table lists the limits beyond which the part may be permanently damaged; it is not a working range. The Recommended Operating Conditions table, always lower, gives the range in which the part is designed to work. If the maximum is 4.0 V, do not run the part at 3.9 V.

Beginners often skip one rule of board design: place a 100 nF capacitor right next to every supply pin of the MCU. Digital logic draws current in very short spikes when it switches, and the supply wiring cannot deliver them fast enough. The capacitor acts as a small local reservoir. Without it, you get random resets and unpredictable behaviour that no code change can fix. Ready-made boards already have these capacitors. Your first PCB design will not, unless you add them.

Real products also must not rely on the code never hanging. A watchdog timer resets the MCU unless the firmware confirms, at regular intervals, that it is running correctly. This is called feeding the watchdog. If the program stops responding, the reset restarts it. Once your project runs unattended, enable the watchdog.