cancel
Showing results for 
Search instead for 
Did you mean: 

STM32G0B0 writing to PD1 affects PD0

LukasLang
Associate

I am running into an issue with the STM32G0B0 MCU: 

Writing to PD1 seems to result in the opposite value being somehow applied to PD0, even though PD0 is set to input.

Effectively, I created a new project in STM32CubeIDE, configured PD0 & PD2 as GPIO_Input (with pullup enabled) and PD1 as GPIO_Output.

Next, I added the following code to the main function:

 

  /* USER CODE BEGIN WHILE */
  while (1)
  {
    /* USER CODE END WHILE */
	  for (int i = 0; i < 100000; ++i)
	  {
	  }

	  GPIOD->BSRR = GPIO_PIN_1;


	  for (int i = 0; i < 100000; ++i)
	  {
	  }

	  GPIOD->BRR = GPIO_PIN_1;
    /* USER CODE BEGIN 3 */
  }
  /* USER CODE END 3 */

 

Running this code on the MCU (the board is effectively empty: There are some bypass caps next to the power pins & two pullup on a couple of other, unrelated pins) results in the following output on the two pins:
LukasLang_0-1721313010010.png
PD2 is DIO5, PD1 is DIO6, PD0 is DIO7.  I have reproduced this behavior on 4 different boards by now.
 
What is going on here? Why is the input pin being affected by the output pin? How can I fix this?
1 ACCEPTED SOLUTION

Accepted Solutions
TDK
Guru

Likely this:

Solved: Strange behavior GPIOD - STMicroelectronics Community

 

If you feel a post has answered your question, please click "Accept as Solution".

View solution in original post

3 REPLIES 3
TDK
Guru

Likely this:

Solved: Strange behavior GPIOD - STMicroelectronics Community

 

If you feel a post has answered your question, please click "Accept as Solution".
LukasLang
Associate

Thanks, that appears to have been it! Just for my understanding: What exactly do those pulldowns do? I.e. how does the pull-down lead to the weird "cross-talk" between the two pins? From cursory reading, it looks to have something to do with USB-C power delivery, but beyond that I can't tell what the exact behavior is.

For future reference: I added the following line in front of the while loop, which appears to have fixed the issue:

HAL_SYSCFG_StrobeDBattpinsConfig(SYSCFG_UCPD1_STROBE | SYSCFG_UCPD2_STROBE);
Amel NASRI
ST Employee

Hi @LukasLang & @TDK ,

Following this discussion, a request for documentation update is tracked internally. A note similar to the following will be added to the pinout table:

"Upon reset, a pull-down resistor might be present on PA8, PB15, PD0, or PD2, depending on the voltage level on PA9, PA10, PD1, and PD3, respectively. In order to disable this resistor, strobe the UCPDx_STROBE bit of the SYSCFG_CFGR1 register during start-up sequence.".

Internal ticket number: 186950 (This is an internal tracking number and is not accessible or usable by customers).

-Amel

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.