Why is my STM32 board resetting randomly during testing?

First thing I'd do is figure out what kind of reset it actualy is, because the C0 tells you. At the very start of main, read RCC_CSR and check the reset flags. BORRSTF means brown-out, IWDGRSTF means the watchdog, PINRSTF means the NRST pin got yanked low. Clear the flags each boot so you only see the latest cause. That one check usally cuts the guessing in half, because a random reset from a timer firing is a totally diffrent animal than a reset from the supply sagging. Nine times out of ten when I've seen this exact symptom on a breadboarded chip, it's brown-out. Your supply module reads a steady 3.3V, but that's at the module. When you start hammering GPIOs and lighting LEDs, the current draw pulses, and if the wires back to the supply are thin jumper wires the voltage at the chip pins dips for microseconds. Your meter will never catch that, but the chip's brown-out detector will. Stick a decent bulk cap, something like 10uF, right at the chip's supply pins in addition to the 100nF decouplers, and see if the problem vanishes. If it does, that was it. Also check NRST. The C0 has an internal pull-up, but on a breadboard that pin is a great antenna. If your probe or a loose wire touches it, instant reset. A small cap from NRST to ground, 100nF or so, makes it a lot less touchy. On the clock side, if you're running off the internal HSI you're pretty safe. But if you switched to an external crystal and turned on the clock security system, a flaky crystal connection will trip it and reset the chip every time the oscillator hiccups. And double check you didn't leave the independent watchdog enabled somewhere, it bites people who copy init code from examples without noticing.

If the flags come back clean and the caps don't help, post your clock init code. There's a setting or two in there that can cause exactly this.

You should look closely at the startup sequence timing, specifically how quickly you're enabling the peripherals after the chip comes up. Sometimes the reset flags are clean, but the subsequent configuration is too aggressive. Even on the C0, if you try to start a peripheral before the HSI has fully settled and been registered internally, you can induce a temporary instability that acts like a soft reset. I once ran into this exact ghost issue on a C0 board when I attempted to configure a high-speed SPI peripheral immediatly after resetting the stack pointer. I learned it was timing-related, not power related. Just adding a minimal delay loop, even one only 100 cycles long, between clock enablement and register write fixes the issue completly.

If you're using HAL drivers, try dropping down into the register level config for the initialization routine and see if that delay resolves the spontaneous reboots.

One more thing I'd check before touching any caps, and that's the BOOT0 pin. On these little packages it's easy to leave it dangling on a breadboard, and a pin that floats can read high or low depending on whatever stray charge is hanging around, so after a reset the chip occasionally wakes up in the bootloader instead of your flash. From the outside that looks exactly like a random restart. Tie it firmly to ground and I suspect some of the weirdness disappears. I chased a similar ghost for two evenings once and it turned out to be exactly that.