STM32WB USB Shutdown: Keep CLK48 Available to the Other Core’s RNG

An idle USB peripheral does not prove that its source clock can be disabled on STM32WB55. CPU2 may still need the same CLK48 source for the random-number generator. The shutdown decision crosses the processor boundary, even when CPU1 never calls an RNG API.

AN5289 Rev 18 describes the ownership protocol using semaphores 0 and 5. Read its USB sequence through the final clock-off step. Treating the semaphores as interchangeable locks misses the dependency that makes this case unusual.

Two resources, two ownership questions

AN5289 section 4.3 assigns semaphore 0 to shared RNG access. It also explains why USB shutdown must acquire this semaphore: USB and RNG share CLK48, and CPU2 can use RNG while CPU1 is finishing USB work.

Semaphore 5 protects the relevant source-clock configuration registers. The note says CPU2 changes or switches off that clock while using RNG under semaphore 0. It also requires CPU1 to use semaphore 5 when changing the listed RCC_CCIPR clock selections, preventing concurrent configuration changes.

These are different questions. Semaphore 5 concerns source configuration ownership. Semaphore 0 supplies the coordination with CPU2's RNG use that is needed before clock removal. A CPU1-only USB reference count cannot represent an RNG operation happening on the other processor.

The RM0434 Rev 16 clock and RNG chapters establish the corresponding hardware selections. Review the actual RCC settings along with the software protocol; peripheral enable state and source-clock availability are separate controls.

Follow the USB sequence to its end

Figure 9 in AN5289 first acquires semaphore 5, configures and enables CLK48, and enables USB. After USB processing, it switches off the USB peripheral, then attempts to acquire semaphore 0.

If semaphore 0 is unavailable, the illustrated flow enables its free notification and waits. Only after ownership is granted does CPU1 switch off CLK48, release semaphore 0 and finally release semaphore 5. Moving the clock-off operation ahead of that acquisition defeats the point of the handoff.

The illustration is not a suggestion to hold an arbitrary CPU interrupt mask throughout a USB session. Follow the framework's hardware-semaphore handling and execution-context requirements. The protected resource and the way the caller waits for ownership must both be explicit in the port.

USB is locally stopped but CPU2 RNG can still need CLK48, so CPU1 acquires semaphore zero before removing the shared clock.
Original clock-ownership diagram. Semaphore 0 coordinates RNG use; semaphore 5 has a separate source-configuration role.

Diagnose both interruption and a clock that stays on

The obvious failure is disabling a source while its peer is using it. AN5289 also identifies a less obvious race: CPU1 releasing USB while CPU2 releases RNG can leave the oscillator running. Thus, a clock that remains enabled after USB shutdown is not automatically an unexplained power leak in the USB block.

Inspect the order of semaphore acquisition, peripheral shutdown, clock removal and release on both sides. A clean local USB completion log says nothing about whether the cross-core clock handoff completed. Conversely, an intentionally delayed clock removal while CPU2 owns RNG is a legitimate intermediate state.

For a proposed development trace, record USB peripheral disable, semaphore-0 acquisition outcome, CLK48 source state and final semaphore releases. Include a case in which CPU2 is using RNG near shutdown, using a supported workload rather than altering the wireless stack. No such trace or power measurement was executed here.

Keep error and cancellation paths inside the same contract

A normal close path may follow Figure 9 while a timeout or disconnect path disables the clock directly. Audit every path that removes CLK48, including shutdown after partial initialization. The fact that USB did not become fully operational does not establish that CPU2 had no RNG activity.

Do not clear a peer-owned semaphore to make shutdown progress, and do not disable required RNG behavior to avoid contention. If the ownership transfer does not complete, preserve that state as the failure to investigate. A forced clock-off would replace a diagnosable coordination problem with an unqualified hardware state.

The release criterion is specific: USB can stop, CPU2's documented RNG clock contract remains respected, and the final source state matches the completed handoff. This is stronger than “the USB driver returned success,” while avoiding an unsupported promise about whole-board power savings.

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *