There are many repeated features in STM32, so it's natural to employ some form of numbering to denote the individual features. In STM32, unfortunately, ST uses - with no particular system - both 0-based and 1-based numbering.

That some of these problems stem from ST compounding STM32 from purchased IP components, is no excuse - it's ST's task to unify style and screen users from malpractices of its suppliers. The current practice made ST's life easier, but it makes the life of thousands of users harder.

Some of particular issues stemming from this problem have been already discussed, e.g. the DMA/DMAMUX numbering mess.

An even more spectacular example is in numbering of the SYSCFG_EXTICR (as experienced painfully e.g by user J.v.W.) - while Reference Manual numbers them 1-based, the CMSIS-mandated header defines them as a standard (thus 0-based) C array; yet the same header also defines symbols which originate from the 1-based numbering. Thus, we then have to write confusing concoctions like:

SYSCFG->EXTICR[3] = SYSCFG_EXTICR4_EXTI15_PB;