Debugging, datasheets and staying safe

The debugger, the two datasheet tables that matter, and the capacitor that stops random resets.

Read this first

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

Datasheets look frightening and are mostly tables. Two of them matter first. 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, is where the part actually works. If the maximum says 4.0 V, do not run it at 3.9 V.

One rule of board design that beginners skip and then pay for: put 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 wire is too slow to deliver them. The capacitor is a tiny local reservoir. Without it you get random resets and strange behaviour that no amount of code fixes. Ready-made boards already have them; your first own PCB will not unless you put them there.

Finally, real products do not rely on the code never hanging. A watchdog timer resets the MCU unless the firmware keeps telling it, at regular intervals, that all is well. If the program gets stuck, the reset brings it back. Once your project runs unattended, turn the watchdog on.

To remember

SWD debugging needs SWDIO, SWCLK and ground. Nucleo boards have the adapter on board, the Pico needs a Debug Probe, the Uno has none.
Absolute maximum is a damage limit, not an operating range.
100 nF next to every supply pin, always.
A watchdog resets the chip if the firmware stops feeding it.

Check what you read

4 questions from the question bank on the ideas above. Each one comes with an explanation after you answer.

The lesson text and the project are free to read without an account.

Build this

First complete device: a small weather station

You need

Everything from the earlier lessons: the board, the I2C sensor, the button, the LED, serial output.
Optional: the OLED display.

Steps

Combine the pieces: read the sensor once a second, show the reading on serial and on the display if you have one, and let the button switch between readings.
On a board with a debugger (Nucleo, or Pico with a Debug Probe), set a breakpoint in the sensor reading code and step through one measurement. Look at the raw register values before they become a temperature.
Look up your MCU's absolute maximum supply voltage and its recommended range and write both down in a comment at the top of main.
Enable the watchdog with a timeout of about one second and feed it in the main loop. Then add a deliberate endless loop behind the button and confirm the board resets itself. From now on, sitting at a breakpoint longer than the timeout also resets the board, unless you tell the debugger to freeze the watchdog while halted (on STM32 that is the IWDG option under DBGMCU), so freeze it or turn it off when you go back to stepping.

Done when

The device runs on its own, you have stepped through it in the debugger, and a hang is recovered by the watchdog without touching the reset button.