Unable to reliably measure the state of a GPIO

[aeddi]

Hello everyone,

My project involves detecting from a Raspberry Pi Pico 2 W whether the USB port of my TV is on or off.
So, I decided to create a voltage divider to reduce the voltage from 5V to ~3V with a current of ~10μA, and I made the following circuit:

Untitled Sketch_bb.jpeg (247.7 KiB) Viewed 1049 times

Untitled Sketch_schem.jpg (111.27 KiB) Viewed 1049 times

But if I try to execute the following code (MicroPython), I only get a state change (0 -> 1) the first time I turn on the USB, then nothing happens.

Code: Select all

from machine import Pin

INPUT_3V = Pin(15, Pin.IN)

current_state = INPUT_3V.value()

while True:
    if current_state != INPUT_3V.value():
        current_state = INPUT_3V.value()
        print("Input state changed to", current_state)

If I unplug the jumper cable between the GND of my RPi and the breadboard, I then get the following result:

• if I turn off the USB, there is no state change

• if I turn on the USB, I get the following logs:

  Code: Select all

  Input state changed to 0
  Input state changed to 1
  

I tried using pull-up / pull-down resistors by adding resistors between my GPIO15 pin and the GND of the RPi or the GND of my breadboard, and by specifying the Pin.PULL_UP / Pin.PULL_DOWN parameters in the MicroPython code, but I can't achieve a better result.

Thank you in advance for your help!

[Mike**K]

How is the Pico being powered?

[aeddi]

How is the Pico being powered?

The Pico is connected as follows:

• powered via its micro-USB port
• connected via UART to the debug probe
• connected via its SWD port to the debug probe

[hippy]

I suspect Errata-E9 may be in play here, causing GPIO input high latching.

I cannot explain exactly what you are seeing reported but the code you are using can be unreliable -

Code: Select all

current_state = INPUT_3V.value()
while True:
    if current_state != INPUT_3V.value():	# X
        current_state = INPUT_3V.value()	# Y

The reading at 'Y' may be different to what it was when read at 'X'. I would recommend something along the lines of-

Code: Select all

now_state = INPUT_3V.value()
while True:
    was_state = now_state
    now_state = INPUT_3V.value()
    if now_state != was_state:
        print("Input state changed to", now_state)

[gmx]

So, I decided to create a voltage divider to reduce the voltage from 5V to ~3V with a current of ~10μA, and I made the following circuit:

This way you will definitely have problems with E9 hardware bug. The resistor to ground should be below 10 k, and the sink current should be above 110 μA, otherwise it tends to remain stuck around 2 V (logical 1).

If I unplug the jumper cable between the GND of my RPi and the breadboard,

Why would you do that?
You can end up with such a high voltage it could destroy the Pico.
At least please save the debug probe.

[aeddi]

@hippy: I just applied your changes but I'm getting exactly the same result as with my code.

@gmx: Ok, I will stop messing around with my GND ( ) and use lower resistances, I'll recalculate my divider to go above 110 μA and keep you updated.

[aeddi]

This way you will definitely have problems with E9 hardware bug. The resistor to ground should be below 10 k, and the sink current should be above 110 μA, otherwise it tends to remain stuck around 2 V (logical 1).

What do you think about replacing my 220k resistor on the 5v with a 14k, and replacing the 330k on the GND with a 22k?
Which would give on the GPIO15, if my calculations are correct: 3.05v and 139 μA.}

Edit: After checking, it seems that the maximum current is 16mA on a GPIO input (I'm not sure about this information). So I could instead use a 1.2k resistor in place of the 220k one and a 2k resistor in place of the 330k one. This would give us on the GPIO: 3.12V 1.56mA

[gmx]

The resistor to ground is acting as a pull-down when 5V voltage disappears.
And it has to overcome around 120uA at 1.2V, hence the 10k resistor (I've thoroughly tested it over time).

The official workaround (in your case can be done also from software, but it's a bit trickier):

Workaround
If pad pull-down behaviour is required, clear the pad input enable in GPIO0.IE (for GPIOs 0 through 47) to
ensure that the pad pull-down resistor pulls the pad signal low. To read the state of a pad pulled-down
GPIO from software, enable the input buffer by setting GPIO0.IE immediately before reading, and then redisable
immediately afterwards. Note that if the pad is already a logic-0, re-enabling the input does not
disturb the pull-down state.

Alternatively an external pull-down of 8.2 kΩ or less can be used.

If you activate the internal pull-down, it can help with a higher resistor, but cannot overcome it alone (too weak).
My first tests: viewtopic.php?p=2248964#p2248964

Besides that, I would use a Zenner diode as protection (or other means), you never know.

[aeddi]

@gmx No problem using a 10k resistor or lower.
To be honest, I do very little electronics and I'm not sure of what the best option is; so can you directly advise me on what kind of circuit to make?
For example:

• What resistor (R1) between 5V and GPIO? Is 1.2k ok?
• What resistor (R2) between GPIO and GND? Is 2 ok?
• Where should I add a Zener diode in the circuit? And with what specifications?

[Tharre]

There's no reason to use stronger pulldowns for this, the software workaround works fine for this use case and doesn't waste a ton of extra power. Just keep the input buffer disabled (GPIO0.IE as described in the errata) until you're actually measuring the pin state and disable it immediately afterwards.

[gmx]

There are many reasons, and a couple of mW is far from a ton of extra power.

For example the circuit used on original Pico2, and some calculations:

Pico2_VBUS.gif (56.58 KiB) Viewed 863 times

Pico2_VBUS_calculations.gif (14.46 KiB) Viewed 863 times

[katak255]

Since the USB port is on a TV, milliamps of power consumption is probably not an issue, so I'll just point out that an optoisolator is an option -- one won't have to worry about overvoltages whatnot or different GND levels.

[hippy]

@hippy: I just applied your changes but I'm getting exactly the same result as with my code.

That is as expected, and also good news.

Under most circumstances the unreliability of the original code probably won't be observed but the unreliability is there and can cause issues when experienced.

[aeddi]

Thanks for all you answers.

Could any of you provide me with a solution in "Explain me like I'm 5" mode, please? Many of the terms you use are unclear to me, or I don't know them at all. Which components should I use, with what specifications (ohms, volts, etc.), and how do I assemble them?

It absolutely doesn't matter if the circuit consumes a few extra mW as long as I can reliably trigger a callback in my code every time this USB port is turned on or off.

[gmx]

What's used on original Pico2:
connected to 5v: 5k6 (instead of your 220k)
connected to ground: 10k (instead of your 330k)

[aeddi]

Ok thanks, I'll try this this evening.

[hippy]

What's used on original Pico2:
connected to 5v: 5k6 (instead of your 220k)
connected to ground: 10k (instead of your 330k)

Is that 10K low enough to un-latch a sticky high input by itself if the ~5V to the divider is removed ?

I believe clearing then setting IE before reading should do the job.

[gmx]

@hippy:

My first tests: viewtopic.php?p=2248964#p2248964

[hippy]

Fair enough but why do Raspberry Pi specify '8K2 or less' rather than 10K which almost everyone would have in their parts drawer ?

But it's worth a try even if it doesn't work for all devices.

[gmx]

Probably to have a conservative margin on full range to the extremes of temperature (-40...85 °C), voltage etc.

But for mere mortals, it works with 10k pretty well (I've tested multiple boards, RP2350 A/B).
Around 15k needs help from internal pull-down activated in parallel, this one is so-so.

Also look on their original Pico2, VBUS detection on GPIO24 is done with 10k...

You can use a potentiometer, see where it jumps, disconnect, and measure the spot resistance with an ordinary multimeter.

[gmx]

Just keep the input buffer disabled (GPIO0.IE as described in the errata) until you're actually measuring the pin state and disable it immediately afterwards.

Another way (for me looks more reliable) is to drive the GPIO down for a brief moment, then disable the output.

[hippy]

Also look on their original Pico2, VBUS detection on GPIO24 is done with 10k...

I noted that. I presumed the user would need to apply one of the Errata-E9 workrounds if they ever wanted to read that reliably.

[Tharre]

There are many reasons, and a couple of mW is far from a ton of extra power.

Such as? I guess if you're using through hole resistors you might get significant enough interference picked up by the leads that could trigger false reading ..
True enough though that 1-2mW don't make a difference in a wall powered USB context, I might be a bit too much in the "every uA matters because of battery life" mindset.

Also look on their original Pico2, VBUS detection on GPIO24 is done with 10k...

They didn't know about E9 at the time they designed that though, right? So you can't exactly take that as a recommendation. Though in practice 10k should work unless you're working in the upper end of the temperature range.

Another way (for me looks more reliable) is to drive the GPIO down for a brief moment, then disable the output.

Seems reasonable, though depending on parasitic capacitance of the wire you may need to wait for a couple of cycles afterwards until the voltage is high enough again to reliably be detected as '1' if the resistor values are high.

[gmx]

Though, to be honest, I usually test what I write.

[gmx]

Another way (for me looks more reliable) is to drive the GPIO down for a brief moment, then disable the output.

Seems reasonable, though depending on parasitic capacitance of the wire you may need to wait for a couple of cycles afterwards until the voltage is high enough again to reliably be detected as '1' if the resistor values are high.

The same parasitic capacitance can keep the pad floating high, or slowly discharging through the weak internal pull-down.
By actively driving down the pad, it get discharged much faster, of course this depends from case to case, for example on a long line it can make (bad) ripples. I will try to see how it gets on a usual USB cable.