GPIO reset values for STM32F3 devices are wrong

[teskje]

It appears that the SVDs for the F3 family (didn't check others) are quite broken with regard to GPIO reset values.

Looking at the RMs, all MCUs in that family have the same debug pins (PA13, PA14, PA15, PB3, and PB4) which are enabled by default. It follows that for all these devices GPIOA and GPIOB are special, while the other ports are all the same. So the PACs should have three modules, gpioa, gpiob, and gpioc for every subfamily. While this is the case for some, others, like stm32f303, only have gpioa and gpiob.

Let's take a deeper look at the correct reset values vs. what the PACs/SVDs think is correct.

Correct GPIO Reset Values

From the RMs, these should be the correct reset values:

• GPIOA:

  MODER   | 0xA800_0000
  OSPEEDR | 0x0C00_0000
  PUPDR   | 0x6400_0000
  

• GPIOB:

  MODER   | 0x0000_0280
  OSPEEDR | 0x0000_00C0
  PUPDR   | 0x0000_0100
  

All values left out are 0x0000_0000.

There is some uncertainty here because the RMs are not the most reliable source of this information:

• Some RMs (F302, F373, F334) list the reset values for the GPIO{C,D,E,...} PUPDRs as 0x0C00000. That means that PUPDR13 is set to 0b11 which is a reserved value, so I'm not sure that is correct.
• The F334 RM lists the reset value for the GPIOA OSPEEDR as 0x64000000, but also as 0x7c00000 in another table. The SVD knows another value entirely (see below).

I unfortunately don't own any of these boards, otherwise it would be easy to gather the right values. I checked on an F303 and the reset values there match the once I listed above.

Reset Values Reported by the PACs

Here are the reset values currently known to the PACs, by sub-family feature. Again I left out zero-values. Wrong values are marked.

stm32f301

• GPIOA:

  MODER   | 0xA8000000
  OSPEEDR | 0x0C000000
  PUPDR   | 0x64000000
  

• GPIOB:

  MODER   | 0x00000280
  OSPEEDR | 0x000000C0
  PUPDR   | 0x00000100
  

• GPIO{C,D,F}:

  PUPDR   | 0x0C000000  ?
  

This looks good, apart from the GPIO{C,D,F} PUPDR. But as mentioned above, this would be correct according to some RMs, so we can give it the benefit of the doubt.

stm32f302 / stm32f303 / stm32f373

• GPIOA:

  moder   | 0x28000000  ✘
  ospeedr | 0x00000000  ✘
  pupdr   | 0x24000000  ✘
  

• GPIOB:

  moder   | 0x00000000  ✘
  ospeedr | 0x00000000  ✘
  pupdr   | 0x00000000  ✘
  

The register reset values are completely off here. The SVD thinks that GPIOB resets to all-zero, which explains why for these sub-families we only have two gpio* modules in the PAC.

stm32f3x4

• GPIOA:

  moder   | 0xA8000000
  ospeedr | 0xC0000000  ?
  pupdr   | 0x64000000
  

• GPIOB:

  moder   | 0x00000280
  ospeedr | 0x000000C0
  pupdr   | 0x00000100
  

• GPIO{C,D,F}:

  pupdr   | 0x0C000000  ?
  

Both values that deviate here are values that the RM also is uncertain about, so for all we know this might actually be correct.

stm32f3x8

• GPIOA:

  moder   | 0x28000000  ✘
  ospeedr | 0x00000000  ✘
  pupdr   | 0x24000000  ✘
  

• GPIOB:

  moder   | 0x00000000  ✘
  ospeedr | 0x00000000  ✘
  pupdr   | 0x00000000  ✘
  

• GPIOH:

  moder   | 0x28000000  ✘
  pupdr   | 0x24000000  ✘
  

Again, this is completely wrong.

---

So from what I gather, we need to at least fix the following sub-families:

• stm32f302
• stm32f303
• stm32f373
• stm32f3x8

This issue currently blocks a refactor of the GPIO module in the stm32f3xx-hal (stm32-rs/stm32f3xx-hal#129), so I'm very interested in getting this fixed. I'm new to svd2rust, so if anyone could give me any guidance to what needs to be done, that would be great!