Posted on September 22, 2015 at 00:33Your pull-up scheme is fine. I tend to prefer having supply thresholding POR circuits, but the STM32 has it's own.
No, my point is if someone uses a push-pull driver to set NRST high (ie off an FPGA or other CPU GPIO pin), the chip can't over come this with it's internal reset circuit, and that malfunctions. The NRST should be driven low by an open-drain, as many devices can generate a reset.
One variant of this issue is things like NVIC_SystemReset() get stuck in a while() loop, or watchdogs fail to do their job as expected. It's a very common issue when migrating to ARM devices.
The other classic failure is that the STM32 can reset everything else on your board sharing the NRST/NRESET net. The thing that usually catches people are the supply thresholds, where the supply browns out, and bang the reset clamps for many milliseconds. This tends to be most surprising to people using RC reset circuits, as they migrate to POR circuits with laser trimmed threshold devices, that clamp for 100ms, this highlights issues with under designed power supply/regulation, or slow rise on supplies. Other ARM devices can get very complicated, with 3 different supply rails, and rules on ordering startup sequences.
