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 · ‎2022-01-04

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?

waclawek.jan · ‎2022-01-04

> 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

THunn.1 · ‎2022-01-04

I am told that LL_SYSCFG_DisableDBATT(LL_SYSCFG_UCPD1_STROBE | LL_SYSCFG_UCPD2_STROBE); soon after start up appears to have fixed the problem. Thank you everyone for your help.