Setting D2 and D3 as GPIO inputs on NUCLEO-G0B1RE and power cycling appears to be causing a permanent short circuit between D2 and D3. Can you give me any knowledge or insight about this?

[THunn.1]

My program sets D1, D2 and D3 up as identical GPIO inputs. All are pull-ups. Tests using STM32CubeIDE in debug shows both working perfectly and independently as the circuit is opened and closed to pull the input down and allowing it to pull up again.

Now the board is power cycled.

The test is repeated using the same code but now D2 is showing as 0 (it is being pulled low despite being open circuit) . Pulling D3 low makes it change from 1 to 0 but now D2 goes from 0 to 1 (it is now being pulled high).

Now power is removed from the board.

Measuring the resistance between D2 and ground shows a different resistance between it and measuring other inputs D1 and D3. Also there appears to be a lower resistance than expected between D2 and D3 but only in one direction.

We have repeated this test on three different NUCLEO-G0B1RE boards and the result has been the same and permanent each time.

Is there anything different about D2 that might explain this change? Is there anything in software that could fix it or protect against this happening?

[Uwe Bonnes]

Did the boards have external connections? Was there external voltage applied, e.g. 5 Volt logic? During powerup, 5-Volt tolerant inputs are not! 5-Volt tolerant !.

Othwerwise, fully erase the G0 and check again.

[THunn.1]

Thank you for your prompt response.

There was no external power supply ... just the power supply from the same USB as used to connect the laptop to the Nucleo-G0B1RE.

Have tried erasing and reapplying code and it does not clear the problem.

[THunn.1]

Are these components sensitive to Static Electric? My colleague believes he may have inadvertently touched the connections. Personally I prod the things all the time and this is the first time I've seen anything quite like this.

[waclawek.jan]

What do you mean by D2 and D3, the Arduino signals (i.e. PA10 and PB3) or PD2 and PD3?

In the latter case, this is the infamous USBC PD dead-battery gotcha - PD2 is UCPD2_CC2 and PD3 is UCPD2_DBCC2, the latter controlling *directly* a transistor switching pulldown in the former (i.e. even without power supply connected). Search the forum for "dead battery".

JW

[THunn.1]

I do indeed mean the GPIOs PD2 and PD3. Thank you ... I will search for "dead battery".

[THunn.1]

I found https://community.st.com/s/question/0D53W00001Co83hSAB/why-does-the-dead-battery-feature-of-ucpd-cause-issues-reading-the-cc-voltage the most interesting. No I don't want to use the dead battery feature ... I want PD2 and PD3 to be GPIO inputs with pull-up resistors. According to the answer given by Igor Cesko (ST Employee) I want to: set the UCPD1_DBDIS bit (in PWR_CR3 register) just after power on.

I'm trying to keep to using the Lower Layer commands provided by ST for the STM32G0. Is there a handy LL_ command to enable me to set this bit?

[THunn.1]

I think I've found what I'm looking for:

__STATIC_INLINE void LL_SYSCFG_DisableDBATT(uint32_t ConfigDeadBattery);

is defined in stm32g0xx_ll_system.h. So a call such as this just after power on should fix my problem:

LL_SYSCFG_DisableDBATT(LL_SYSCFG_UCPD1_STROBE | LL_SYSCFG_UCPD2_STROBE);

[waclawek.jan]

The main issue here is, that the relationship between the pins is present even during powerdown/reset. If this does not matter for your application, using PWR_CR3.UCPDx_DBDIS [see edit below] is fine (note that PD2/PD3 are related to UCPD2).

> Is there a handy LL_ command to enable me to set this bit?

I don't know, I don't use Cube (and I see absolutely no reason to use LL, which IMO just confusingly renames register accesses). But Cube is open source and this is a single write to a register, you should be able to find this easily in Cube sources.

JW

[EDIT] Confusingly, the DBDIS bits in 'G0 are in SYSCFG_CFGR1, not in PWR_CR3 as they are in 'G4...

[THunn.1]

Thank you. You're right about the different names used on the different MCUs... hence the reason why I want to use the LL_ commands to produce a reasonable level of abstraction despite all the underlying differences. I don't think my application cares about what happens during power down but it is something that I will need to keep an eye on.

[waclawek.jan]

> hence the reason why I want to use the LL_ commands to produce a reasonable level of abstraction despite all the underlying differences

In CubeG4, the functionality in question is disabled by LL_PWR_DisableUCPDDeadBattery() and there's probably no LL_SYSCFG_DisableDBATT().

In other words, LL is not suitable for this kind of "abstraction", or to facilitate porting. IMO, LL is there just to fulfill the desire of users to have *some* "library". (I'd love to know the reason for this desire - my theory is that it's result of modern education in CS (i.e. students are told by academics that libraries and abstraction are a necessity), but TDK and Clive here are as prime examples to disprove this theory, as neither of them formally studied CS, AFAIK.)

It's your choice, nonetheless.

JW