Reset state of certain GPIOs in STM32G431x has unknown behaviour(s)

[MagSense]

Hi everyone,

I am currently migrating from STM32F303x to STM32G431x microcontroller (48-pin package) and started testing the GPIOs in reset state, without any firmware on-board. Also, there are no external HW circuitries connected to the pins (I meantioned in my description below). The power pins are connected with voltage supplied from a 3.3V LDO, without any high noise on the lines.

The NRST pin is connected to GND with a 100nF capacitor.

I observed some strange behaviour which I could not get an answer from the datasheet/application note/presentations and I would like to post here and get some answers, possibly.

1. PA2 is tied to VDD and has alternate function of UCPD1_FRSTX. Why is it tied to VDD?
2. PA5 "controls" the state of PA6. Whenever PA5 is HIGH, PA6 goes HIGH. PA5 has alternate function of UCPD1_FRSTX but PA6 has no connection with UCPD peripheral. Why such behaviour happens?
3. PA6 is tied to VDD. Why is it tied to VDD?
4. PB14 has, by far, the most strange behaviour. It is tied to VDD and has no special alternate function (other than UART, SPI, TIM, COMP). It always complements the state of PB12 i.e., whenever PB12 is HIGH, PB14 goes LOW and vice versa. Apart from this, PB14 has a strange relationship with PB13. Whenever the state of PB13 changes (LOW -> HIGH or HIGH -> LOW), the outcome is unpredictable on PB14. It might not change its state, or it might change its state (permanently/temporarily). This is completely strange and would love to get some thoughts on it.
5. PA9 is tied to VDD (10 ohms) and it can be because of the UCPD_DBCC1 alternate function. According to RM0440 (section 46.4.6), this pin should be tied to GND when it is not required. However, the current consumption shoots up when this pin is short to GND (>60 mA). This is not the case with PA10, which has UCPD_DBCC2 alternate function. It has an internal pullup of 40k, so I can short it to GND pretty easily. Why such behaviour happens?

The following documents were referred before I posted the question here.

1. https://www.st.com/resource/en/datasheet/stm32g431cb.pdf
2. https://www.st.com/resource/en/reference_manual/rm0440-stm32g4-series-advanced-armbased-32bit-mcus-stmicroelectronics.pdf
3. https://www.stmicroelectronics.com.cn/content/ccc/resource/training/technical/product_training/group0/33/d9/62/8f/29/26/43/df/STM32G4-Peripheral-USB_Type_C-Power_Delivery_UCPD/files/STM32G4-Peripheral-USB_Type_C-Power_Delivery_UCPD.pdf/_jcr_content/translations/en.STM32G4-Peripheral-USB_Type_C-Power...
4. https://www.st.com/resource/en/application_note/an5093-getting-started-with-stm32g4-series--hardware-development-boards-stmicroelectronics.pdf
5. https://www.st.com/resource/en/application_note/an4899-stm32-microcontroller-gpio-configuration-for-hardware-settings-and-lowpower-consumption-stmicroelectronics.pdf
6. https://www.st.com/content/ccc/resource/technical/document/application_note/group1/87/f0/7b/96/37/cf/49/b8/DM00442720/files/DM00442720.pdf/jcr:content/translations/en.DM00442720.pdf

I might have missed something from these references. It will be great if you can provide me some insights into them. Thanks!!

[MagSense]

Hi JW,

The test was conducted at first on a fresh chip. where there is no firmware flashed (ideally). After flashing the firmware, I erased it using the STM32 Cube Programmer software, where you have the option "FULL CHIP ERASE".

How is the aforementioned actions on multiple pins (analog, digital) can be explained by the bootloader? It will be great if I can have some information on this.

[waclawek.jan]

And did you try the same test also after erase?

> How is the aforementioned actions on multiple pins (analog, digital) can be explained by the bootloader?

As I've said "maybe in some devious way", i.e. not running "normally".

How is BOOT0 pin connected, and how are the option bits set?

JW

[MagSense]

Hi JW,

> And did you try the same test also after erase?

Yes. I tried it after performing a full chip erase. I performed such operation on three different test setups with similar configuration of GPIOs mentioned in the description. The result was same on all the three.

> As I've said "maybe in some devious way", i.e. not running "normally".

Should I contact a FAE regarding this, inorder to obtain more information? Or do you have any other suggestions regarding this?

> How is BOOT0 pin connected, and how are the option bits set?

The BOOT0 pin is held high on two test setups during startup and then changed to LOW manually. Since I have plans to use this pin for other peripheral (CAN), I held this high to simulate the pull-up resistor inside a transceiver.

On another sensor, it is left floating.

Since we are speaking about µC without any firmware from my side, does the option bits have a role to play here? I thought it can only be set in the firmware.

During flash process, the following bits are used.

nSWBOOT0 = 0

nBOOT1 = 1

nBOOT0 = 1

Thanks!

Regards,

MagSense.

[MagSense]

Hi JW,

I think your answer already makes sense.

Eventhough it has been specified that the BOOT0 pin shall be used for other purposes, its state during startup makes a great influence on the other pin behaviours. I repeated the tests where all the three test setups had the BOOT0 connected directly to GND, and the behaviour is normal.

I tried to pull it down with 1k ohm resistor, but it did not help me. I had to connect it directly to the GND at the startup to have a normal behaviour, and then can switch states as per my wish on this BOOT0 pin.