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

2 REPLIES 2
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);