STM32L4 never wakes from Stop mode — button EXTI interrupt just doesn't fire

Almost certainly a line-sharing conflict, and PB13 is exactly the pin that makes this bite people. Is anything else in the project using PC13? On a Nucleo board that's the onboard User button (B1), and it's very common to have it wired up for something else in the same project — even just as a secondary debug input, or left over from an earlier version of the firmware.

Here's the mechanism: STM32's EXTI lines are numbered 0–15, and each number corresponds to "pin N on whichever port you've routed it to" — but only one port at a time can be routed to a given line number. PB13 and PC13 are both "pin 13," so they both compete for EXTI13. The routing lives in SYSCFG->EXTICR[3] (EXTICR4 covers lines 12–15), and HAL_GPIO_Init() overwrites the relevant EXTICR bits every time you initialise a pin in EXTI mode — with no warning that it's stealing the line from whatever was there before.

So if MX_GPIO_Init() configures PC13 as EXTI first (because CubeMX generates pins in port/pin order, and it's auto-added as the User Button), then your PB13 init runs after it and reassigns EXTI13 to port B — that part is actually fine, PB13 wins in that case. But if you've got PC13 configured anywhere after your PB13 init (a library, a later manual call, a HAL_GPIO_Init() you added for a different feature), it silently steals EXTI13 back to port C. Your button's rising edge on PB13 then does nothing at all, because the EXTI13 line is now watching PC13 instead — which explains why it works fine when you trigger it from the debugger (you're calling the ISR/callback directly or the GPIO state happens to line up during your test) but never actually fires from a real button press in Stop mode, where the last SYSCFG_EXTICR write before you enter Stop is what determines which port actually wakes you.

Fastest way to confirm: drop a breakpoint after all your MX_xxx_Init() calls and read SYSCFG->EXTICR[3] directly in the debugger's watch window. Bits [7:4] of that register hold the EXTI13 port selector — 0000 = PA, 0001 = PB, 0010 = PC. If it's not 0001, that's your bug, and you'll find the last HAL_GPIO_Init() call touching pin 13 on some other port somewhere in your init order.

Two ways to fix it: reorder your inits so the PB13 config genuinely runs last (fragile — breaks again the next time someone touches init order), or just move your wake button off pin 13 entirely onto a pin number nothing else in the project uses. That second option is the one I'd actually ship.