How do I configure the pullup on GPIO_PIN 6 for STM32G031J6

[Radiofan]

Problem is that the voltage does not rise to 3.3V, I measure it at 1.64V. The pin has nothing connected to it and I tried this on 2 MCUs.

Using STM32CubeIDE 1.2.0 Build: 5034_20200108_0926, I created a simple project and configured pin PB6 as GPIO_INPUT. In the GPIO configuration I set PB6 to pull-up. Nothing else configured, everything else is at default settings. The code generated looks correct:

static void MX_GPIO_Init(void) {

 GPIO_InitTypeDef GPIO_InitStruct = {0};

 /* GPIO Ports Clock Enable */

 __HAL_RCC_GPIOB_CLK_ENABLE();

 /*Configure GPIO pin : PB6 */

 GPIO_InitStruct.Pin = GPIO_PIN_6;

 GPIO_InitStruct.Mode = GPIO_MODE_INPUT;

 GPIO_InitStruct.Pull = GPIO_PULLUP;

 HAL_GPIO_Init(GPIOB, &GPIO_InitStruct);

}

NRST_MODE in the user option bytes is set to 1, but this shouldn't affect anything.

It's almost as if this pin is bonded to something else that is trying to pull it low. What can I do to get this pin working?

[KnarfB]

Are you using the DISCO board (==ST-LINK connected) or the bare MCU chip? Is SWD connected, e.g. for flashing?

[Radiofan]

This is a bare MCU that has been soldered to a SOIC-8 -> 8 pin DIL adapter, with only VDD and VSS connected at the time of measurement. There are of course decoupling cpacitors across the supply.

It's a bit of a puzzle, I am thinking there might be some internal chip bonding to NBOOT or SWCLK.

[TDK]

PB6 is also PA14 which is SWCLK. This is initialized as SWCLK with a pulldown at reset.

Try de-initializing PA14.

Not real sure how the internals work when pins are shared.

[Radiofan]

I believe the pins are just connected together, so if PA14 is confgured with a pull-down, it will be fighting my pull-up on PB6. It certainly looks like this is what's happening.

However, SWCLK should only be initialised once the bootloader is activated. In my scenario, I don't have the DISCO connected, so upon power-up, it should just run my project code.

I am away from the project for a few days, but I will check the STM32CubeIDE generated code for any configuration of PA14 when I get back. I'll give PA14 a HAL_GPIO_DeInit while I'm at it...

[TDK]

> However, SWCLK should only be initialised once the bootloader is activated.
Why do you think that?
The GPIO register values on reset are listed in the RM. SWD interface is definitely active by default.

[Radiofan]

Ah yes, I see it in footnote 4 on page 39 of DS12992-REV2. Big learning curve this MCU, so much documentation to get through. Always read the fine print =)

STM32Cube should really take care of this, with a warning or generated code for PA14.

So will HAL_GPIO_DeInit() put it into high-impedance input mode or restore it's defailt state of having a pull-down?

[waclawek.jan]

Read Cube's documentation, or directly HAL_GPIO_DeInit(), is open source.

Or don't use it at all, and perform the needed register writes yourself.

Be sure you have some way to restore programmability (i.e. retain NRST, to be able to connect under reset).

JW

[TDK]

> Ah yes, I see it in footnote 4 on page 39 of DS12992-REV2. Big learning curve this MCU, so much documentation to get through. Always read the fine print =)

There are definitely some gotchas, the SWD interface being active on reset is one of them. The reference manual is typically a better source of information than the datasheet, although they are meant to be used in parallel.

> STM32Cube should really take care of this, with a warning or generated code for PA14.

STM32CubeMX has everything in RESET_STATE by default, which in this case is the same as SYS_SWCLK. Less of an issue on other chips where pins are not physically tied together. Having it deinitialize the SWD interface by default would certainly cause more issues and user headaches than leaving it alone. I could see it highlighting the default state, but of course developer resources are always limited.

> So will HAL_GPIO_DeInit() put it into high-impedance input mode or restore it's defailt state of having a pull-down?

Definitely look at the code if you want to know for certain. Here is part of what it does, which shows the pullup/down being disabled.

 /*------------------------- GPIO Mode Configuration --------------------*/
 /* Configure IO Direction in Input Floating Mode */
 GPIOx->MODER &= ~(GPIO_MODER_MODER0 << (position * 2U));
 
 /* Configure the default Alternate Function in current IO */
 GPIOx->AFR[position >> 3U] &= ~(0xFU << ((uint32_t)(position & 0x07U) * 4U)) ;
 
 /* Deactivate the Pull-up and Pull-down resistor for the current IO */
 GPIOx->PUPDR &= ~(GPIO_PUPDR_PUPDR0 << (position * 2U));
 
 /* Configure the default value IO Output Type */
 GPIOx->OTYPER &= ~(GPIO_OTYPER_OT_0 << position) ;
 
 /* Configure the default value for IO Speed */
 GPIOx->OSPEEDR &= ~(GPIO_OSPEEDER_OSPEEDR0 << (position * 2U));

[Radiofan]

Thanks for confirming it, I shall update this post with my results towards the end of the week.

RE STM32Cube

> I could see it highlighting the default state, but of course developer resources are always limited.

This problem originally manifested itself as excessive current draw in a project that uses all 6 IO pins, it has taken me hours to isolate this issue to PB6. I won't be the last person to be tripped up by this, a few hours by ST developers will save many hours of debugging for many STM32G0 users.

Warning users about a pin clashes is the one thing STM32Cube must do properly. Is there any way I can raise a defect or enhancement request with ST?

[Radiofan]

Well, I tried DeInit of PA14 as well as clearing the STROBE bits

 HAL_GPIO_DeInit(GPIOA, GPIO_PIN_14);
 // UCPDx_STROBE bit of the SYSCFG_CFGR1 register
 CLEAR_BIT(SYSCFG->CFGR1, 0b00000000000000000000011000000000);

Problem still there.

[KnarfB]

What worked for me is defining PA14 as GPIO input instead of PB6. This moves PA14 away from the reset value SYS_SWCLK thereby disabling the pull-down.

[Radiofan]

Using PA14 instead of PB6 worked! Thanks.