STM32G070KB PA8 and PA9 interaction

[Trilys]

Hello,

We have run into a weird behaviour with the STM32G070KB. With PA8 defined as an input with internal pullup and PA9 as output push-pull.

When PA9 is at low level and PA8 unconnected, PA8 is at VCC (3.3V) as expected.

When PA9 is at high level, PA8 drops to 0.29V. Adding an external 10k pull up raises PA8 to around 1V.

Actually after more tests, leaving PA9 as an input and driving it externally to VCC also makes PA8 to drop.

We are using a custom board, but at this point after unsoldering components and cutting traces, both PA8 and PA9 are not connected to anything so this is not due to external components.

This code sample reproduces the behaviour :

int main(void)
{
	SET_BIT(RCC->IOPENR, RCC_IOPENR_GPIOAEN);
	//Set PA8 as input pull up
	GPIOA->MODER &= ~GPIO_MODER_MODE8;
	GPIOA->PUPDR |= GPIO_PUPDR_PUPD8_0;
	//PA8 reads 3.3V as it should
 
	//Set PA9 as output push-pull low
	GPIOA->MODER &= ~GPIO_MODER_MODE9_1;
	GPIOA->OTYPER &= ~GPIO_OTYPER_OT9;
	GPIOA->BSRR = GPIO_BSRR_BS9;
	//PA8 reads 0.29V at this point
 
 
 while (1)
 {
 
 }
 
 return 0;
}

Why is this happening ? How can we avoid it ?

Best regards,

Geofrey MARCEL

[waclawek.jan]

The 'G070 is a "downgraded" 'G071 (the same chip, just with less testing). PA8 and PA9 are UCPD pins. Read the 'G071 RM to understand the potential reason for your problem.

https://community.st.com/s/question/0D50X0000Az2By8SQE/open-drain-pin-is-pulling-down-slightly-on-stm32g081rb

JW

[Trilys]

Thank you Jan, adding :

SET_BIT(SYSCFG->CFGR1, SYSCFG_CFGR1_UCPD1_STROBE);

fixes the problem.

I did spend quite some time looking the datasheet of the G070 to see what could cause this behaviour... Well, having to look the RM of another part to set something in a register that is not supposed to exist is not so nice... HAL did not helped here either.

So if I get this right, G070 is the same than G071 and can be used the same way ? It is just that some functionnality is not guaranteed ?

[waclawek.jan]

> So if I get this right, G070 is the same than G071 and can be used the same way ? It is just that some functionnality is not guaranteed ?

Probably yes, but ST may be free to disable any functionality using any internal undocumented means, if they chose to. Also, should there be substantial interest in the stripped-down chips, they can produce a new maskset, omitting the "unavailable" functionality, to optimized chip area.

JW

[waclawek.jan]

@Imen DAHMEN​ ,

Can you please suggest adding to the USB PD / Dead battery support subchapter of GPIO chapter in RM0444 at least a one-liner explaining that applications . which don't want to use UCPD, should set the respective SYSCFG_CFGRx_UCPDx_STROBE bits? Best to explicitly mention the given pins (e.g. PA8), so that it could be found using textual search.

As this thread shows, this chapter should also be present in RM0454 (it is now but as a caution *not* to remove it in future), even if there is no official UCPD support in 'G070, maybe with some slightly modified title?

JW

[Imen.D]

Hello Jan,

Ok, I will work on this topic and will raise internally your feedback.

Thank you for your feedback and comments for improvements.

Regards,

Imen

[waclawek.jan]

Thanks, Imen.

Jan

[Imen.D]

Hi Jan,

After discussion with the appropriate team regarding your feedback, we will add a note in the Datasheet pinout table directly. The target and idea right now is not to modified GPIO chapter, which is transparent to it at logic level.

I hope this suggestion would fit your request?

By the way the limitation and strobe action is also present and must be taken in STM32G070.

Best Regards,

Imen

[waclawek.jan]

> By the way the limitation and strobe action is also present and must be taken in STM32G070.

I don't understand. Are you here talking about ES0418 - Rev 1 erratum 2.10.1 UCPD wrong R pdb default trimming value after power-on ?

> we will add a note in the Datasheet pinout table directly

That's a good idea.

> not to modified GPIO chapter, which is transparent to it at logic level.

I understand. However, you already have a sub chapter in the GPIO chapter dedicated to *exactly* this item - USB PD / Dead battery support ... except that it has just some placeholder text there as of now. So, it obviously is planned to talk about it in the GPIO chapter already...

But, as a broader view, I would suggest to add a dedicated chapter - "things that influence pins yet are not influenced by the settings in GPIO" - to *all* STM32 RMs. There are quite a few of them across the STM32 families - OTG USB pins in the 'F4/'F2, oscillator pins, RTC pins, just to name a few.

Jan

[Imen.D]

> I don't understand. Are you here talking about ES0418 - Rev 1 erratum 2.10.1 UCPD wrong R pdb default trimming value after power-on ?

No, there is no bug. You talked about limitation, but the product is like that, so nothing will be in Errata.

The point you described is the same for G070 and G071.

Regards,

Imen

[KPeso.1]

Hi all,

Where did you add the line: SET_BIT(SYSCFG->CFGR1, SYSCFG_CFGR1_UCPD1_STROBE)? I have added it before and after GPIO init, but it seems not to disable the pulldown on PA8 pin on my G070KB (32pin). I have PA9 configured as UART_TX. Is there something else needed to set/reset in the registers to get this worked around?

[Magypko]

Hi all,

I have same problem with STM32G030 (32 pins). I set PA9 and PA8 as input  using CubeMX. PA8 with internal pull-up. When connect PA9 to 3V,  PA8 going down  ?!  ( PA8 is connected only to oscilloscope)

I try trick with SET_BIT(SYSCFG->CFGR1, SYSCFG_CFGR1_UCPD1_STROBE) but, g030 haven't  UCP bits. I add manually before SET_BIT:

#define SYSCFG_CFGR1_UCPD1_STROBE (1 << 9)
#define SYSCFG_CFGR1_UCPD2_STROBE (1 << 10)

and now it's compiling and working.  It this correct? To set bits in SYSCFG when they not present in documentation?

RM0454 on page 40 says: UCPDx_STROBE bits  = "No" for STM32G030!