STM32G070RBT possible GPIO silicon bug?

[NFaut.1]

Hello,

We've been using STM32 for quite some time for multiple products.

For a new design we would like to use the STM32G070RBT. However there is a strange behavior with GPIO PD0 and PD1:

PD0 is configured as input with pullup enabled. PD1 is configured as output push-pull.

When toggling PD1, PD0 changes it's voltage level. When PD1 is set low, PD0 is at 3.3V (as one would expect), and reads digital high. However, if PD1 is set high, PD0 is at 0.4V and reads digital low.

This "crosstalk" has been tested with multiple chips bought from Mouser, as well as with the NUCLEO-G070RB board to make sure it's no hardware issue.

The behavior is the same for code generated with CubeMX (using HAL) as well as with libopencm3. I also checked the peripheral registers using Segger Ozone to make sure the config is correct and no alternate functions are active.

This leads me to think this might in fact be a silicon bug, which would be very unfortunate for our application.

Please let me know if you have notice such behavior and can reproduce this issue.

Thanks and best regards

Niklas Fauth

go-e GmbH

[NFaut.1]

After some more research, I found this post: http://mcu.eetrend.com/content/2019/100044303.html

This fixes the issue. HAL_SYSCFG_StrobeDBattpinsConfig(SYSCFG_CFGR1_UCPD2_STROBE); in between HAL_Init(); and SystemClock_Config();.

This should really be fixed in the HAL somehow. Given I wasted > 5h debugging reading a digital pin.

Best regards

Niklas Fauth

[Imen.D]

Hello @NFaut.1​ 

Please share your ioc file, this will help our team to reproduce the issue.

Best Regards,

Imen

[NFaut.1]

Hey Imen,

Sure! The setup is very simple, it's really just PD0 as input-pullup, and PD1 as output-pushpull.

Please find attached the CubeMX file.

In main.c, I added the following User Code:

/* USER CODE BEGIN 3 */
 HAL_GPIO_WritePin(GPIOD, GPIO_PIN_1, 1);
 HAL_Delay(500);
 HAL_GPIO_WritePin(GPIOD, GPIO_PIN_1, 0);
 HAL_Delay(500);

Now you can look at PD0 with an oscilloscope and see the voltage change from 0.4V to 3.3V, as the inverted state of PD1.

Best regards

Niklas

[waclawek.jan]

This (and related) is a recurring issue in 'G0.

https://community.st.com/s/question/0D50X0000BTdwacSQB/stm32g070kb-pa8-and-pa9-interaction

JW

[NFaut.1]

Thanks!

Yeah, would have saved me a lot of time if I knew earlier this kind of issue exists.

It drove me crazy debugging this like... This isn't any complex DMA transfer or cutting edge timer voodoo... It's literally just reading a digital IO.

I really hope ST will integrate this fix in the HAL or at least put a big note in either the datasheet or the reference manual. Even in the Errata there is no single hint about this :\

So far, my experience with STMs has been excellent, especially with bugs, compared to other vendors.

I really like the G0 series, but I hope this won't get worse...

Best

Niklas