STM32H563 USART Stop Wakeup: Budget the First Character Before Reusing the Run-Mode Baud Rate

An STM32H563 USART can receive reliably in Run mode yet lose the first character after Stop. When the USART kernel clock is initially off, the incoming start edge must first request and establish the clock needed for reception. Correct baud programming while that clock is already running does not prove that this startup fits the first character’s sampling budget.

This review selects USART1, asynchronous reception, Stop mode, an HSI kernel-clock configuration that is initially off and requested on reception, FIFO disabled and no receive DMA. RM0481 Rev 5, Tables 624–625 and 632, establishes the instance and Stop-wakeup context. LPUART, Standby and arbitrary H5 variants are outside this example.

Separate receiver startup from eventual CPU execution

Section 56.5.22 explains that a falling RX edge can request the stopped usart_ker_ck. The peripheral then uses that clock to receive the frame. If the configured wake event is verified, the MCU wakes; if it is not verified, the clock request can be released while the MCU remains in low power.

Select and document the actual wake condition. Start-bit detection, a received frame and address matching are different triggers. For start-bit wake, the manual places the wake event at the end of the start bit. An observed wake interrupt therefore does not independently prove that the intended first data character was received correctly.

More precisely, section 56.5.9 defines tWUUSART from detection of the start-bit falling edge until the requested clock is ready and reaches the peripheral and the regulator is ready. That is the timing quantity relevant to the receiver’s startup contribution.

Put startup into the complete deviation budget

The manual requires total deviation to stay below the applicable receiver tolerance:

DTRA + DQUANT + DREC + DTCL + DWU < receiver_tolerance

The terms cover transmitter error, receiver baud-rate quantization, receiver oscillator error, transmission-line effects and low-power sampling displacement. They share one budget; a design cannot spend the full tolerance on startup while also assuming a nonzero oscillator error for free.

For the manual’s M[1:0] = 01 case, its startup term is:

DWU = tWUUSART / (11 * Tbit)

Other word-length selections use different denominators. The tolerated percentage also depends on oversampling, sampling configuration and baud-register settings. Do not reuse the factor or tolerance from one register combination in an unrelated eight-bit serial configuration.

As the bit time becomes shorter, the same startup delay occupies a greater fraction of the character. That explains why lowering baud can expose this particular mechanism, but a successful slower test alone does not identify every possible cause of a missing byte.

Read the numerical example as a worked assumption

Page 2645 selects OVER8 = 0, M[1:0] = 01, ONEBIT = 0 and BRR[3:0] = 0000. For those settings it uses 3.41% receiver tolerance. Its illustrative receiver-oscillator error is 1%, with the other listed errors idealized as zero.

The resulting paper calculation is:

DWU budget = 3.41% - 1.00% = 2.41%
assumed tWUUSART = 3 microseconds
Tbit boundary = 3 microseconds / (11 * 0.0241)
              = approximately 11.32 microseconds
baud boundary = approximately 88.36 kbaud

The reference manual explicitly labels those values as examples. Neither the assumed three microseconds nor the resulting baud boundary is an H563 board guarantee. Because the governing condition is a strict inequality, an actual design also needs margin rather than treating the rounded boundary as an automatically qualified operating point.

Retain every input’s source, conditions and maximum or typical status when developing a real limit. If the applicable startup bound is unavailable, the numerical qualification remains open. Substituting an attractive nearby timing number does not close it.

Do not substitute the datasheet’s CPU wake time

DS14258 Rev 6, section 5.3.7 and Table 39 defines its low-power wake timings from the wake trigger to the first CPU instruction. The stated measurements use their listed voltage, clock, regulator and flash conditions.

That endpoint differs from the receiver-startup endpoint above. A CPU wake number must not silently become a universal RX-edge-to-usable-kernel-clock value. Likewise, a GPIO toggled by the first interrupt handler measures a later software-visible event, including execution overhead; it is not a direct measurement of the receiver’s sampling readiness.

Keep those two traces separate when explaining a failure. The core eventually running can coexist with an incorrectly sampled first character.

Qualify the first character independently

Before entering the selected mode, apply the documented receiver and wake configuration, including UESM and the chosen wake-source/interrupt settings. After receiver initialization, check REACK as required. The manual warns that checking BUSY alone does not eliminate every entry-during-reception race.

A proposed recoverable bench comparison holds baud, word length and peer waveform constant between Run and Stop. Use a controlled idle gap and a known first character. Record the RX waveform, actual wake configuration, received data and raw error status, then distinguish first-character integrity from later CPU service.

No such test or board-specific maximum baud measurement was performed. Noise, format mismatch, overrun and applicable device errata remain alternative explanations. The useful result here is a specific startup-budget hypothesis and an acceptance record that cannot mistake eventual wakeup for successful first-character reception.