STM32U5 nRST odd behavior

[WTR]

Problem:

    nRST appears to leave the STM32U5 inoperative when applied at any time other than following
application of power. Serial traffic is expected through UART4 following a reset. When the board
is powered on, the STM32U5 software runs as expected; initial traffic through UART4 and then
the STM32U5 interacts through UART4, accepting typed in commands and producing expected
response traffic.

If the reset switch (SW1) is used to reset the STM32U5, it does not produce the expected serial
traffic and no longer communicates through UART4.
A power-cycle of the board produces expected serial traffic and the board interacts (through
UART4) as expected.

The board does not reset correctly after being programmed (using a STLINK-V3SET program-
mer). The program flash is, however, correctly programmed. The updated flash image works fol-
lowing a power-cycle.

This schematic fragment shows power, BOOT0, nRST and programming connections to the
STM32U575RIT6 (U1 is 64LQFP package). Bulk capacitor(10UF) appears elsewhere on the
schematic near the 3.3V (linear) regulator. Voltage levels appear correct and there appears not
to be any excessive noise on the 3.3V rail.
The STM32U5 is being clocked internally (HSI at 16MHz). The clock seems to be working cor-
rectley as evidenced by the STM32U5 being able to communicate through UART4 (U1$UART4)
at the programmed rate of 115,200 b/S.

Looking at logic levels on either side of R4, they appear to be clean and are at expected levels
(near ground and 3.3V) when using SW1 to control U10 output. No excessive noise is apparent.
Although a .1UF cap on the nRST net was missed in the initial board layout, a cap was added to
the board as indicated on the schematic fragment (HAYWIRE note).

I get the impression that I have missed some setup feature in CubeMX (or similar ??) that alters
the default behavior of the nRST pin. nRST starts (follow application of power) in one mode/s-
tate and the software alters this? Popping the reset button (i.e. assert nRST) after the change
(somehow) prevents nRST from behaving correctly?

Thoughts?

Regards & Thanks

_Willy

[TDK]

Attach a debugger to the chip in the "not working" configuration and examine the state. See where execution is at, see if peripherals are enabled, etc. You can do this without resetting the chip.

> I get the impression that I have missed some setup feature in CubeMX (or similar ??) that alters
the default behavior of the nRST pin. nRST starts (follow application of power) in one mode/s-
tate and the software alters this? Popping the reset button (i.e. assert nRST) after the change
(somehow) prevents nRST from behaving correctly?

What gives you that impression? Stay objective, don't guess. Is there anything in the option bytes that can change how NRST is handled?

[Andrew Neil]

---

@TDK wrote:

Attach a debugger to the chip in the "not working" configuration and examine the state ... You can do this without resetting the chip.

---

@WTR Also without downloading - instructions here.