STM32 gotchas

This is a collection of more or less unexpected or surprising behaviour of STM32 microcontrollers, whether documented or not. What constitutes a gotcha is subjective, and some of the items here are not gotchas at all, just poiting out a feature or idiosyncracy, which may be surprising for some. Also, some of the items are not STM32-specific at all, but apply more broadly to ARM Cortex-M-based mcus, or are related to C or programming generally.

This collection will grow, check back or subscribe to the RSS if you want to follow. Oh yes, no social media, learn how to use real information sources.

Many items are a result of discussion at STM32 forum at community.st.com. I'll try to give relevant links to forum threads where applicable, but they have changed in the past and may do so in the future too, and I won't be able to go and fix all of them.

There's no particular ordering or sorting, it would be hard to find out something half-sane, so just browse through and enjoy.

Legalese: STMicroelectronics registered STM32 as a trademark in various countries, although I don't exactly know what are the ramifications of this, I am not a lawyer. I am not affiliated with ST. In what I write here I may be completely wrong, use below information at your own risk.

Comments are welcome, email them to stm32 at efton dot sk.



  1. Peripheral clock must be enabled in RCC (else registers cannot be written and read as 0)
  2. Timers' clock is 2x APB clock, if APB divider > 1
  3. Advanced timers (TIM1, TIM8, ...), to enable output, need to set TIMx_BDTR.MOE
  4. Debugging is intrusive (e.g. UART/SPI Rx may not work when debugging)
  5. 'F4/'F2 CCM RAM is not good for DMA nor for bit-banding, nor for code
  6. RTC seemingly does not run if only time is read
  7. Interrupt called without reason (late interrupt source clear)
  8. Timer does not work if ARR=0
  9. TIMx->SR &= ~TIM_SR_flag results in lost interrupts (don't RMW or bit-band on status registers)
  10. Strange behaviour after increasing system clock frequency (FLASH latency has to follow system clock)
  11. DAC output does not go rail-to-rail and the output buffer makes it worse
  12. UART parity bit missing as it counts up to data bits
  13. Delay is 1ms longer than required (SW/library, not STM32-specific)
  14. GPIO is not toggling at a rate promised by datasheet
  15. Timer appears to run slower then is set (unrealistically high interrupt rate)
  16. Interrupt does not fire - some troubleshooting hints
  17. Program freezes after enabling an interrupt
  18. ADC readings not as expected because of high signal impedance
  19. Debugger keeps jumping into interrupt when single stepping on 'F746