Latching behaviour with Pin.PULL_DOWN (RP2350-E9)

[helgibbons]

Originally posted by @anglerfish27 in https://github.com/pimoroni/pimoroni-pico-rp2350/issues/21#issuecomment-2515816337

I've messed around with a bunch of the u2f's here, currently on the wireless, the hardware is a pimoroni pico plus 2w.

I'm rusty and going back through the fundamentals for fun I'm doing the "Getting started w/Micropython" printed by RPI.

This is a simple example, you setup an input as a pull down and then hook it up to a button who's other connection is the 3.3V rail. You do a simple while loop and it prints "you pressed the button" if you press it, or nothing if you dont.

Well.. its goofed up, I've tried several pins and they all seem to behave the same. Yank the power plug to start fresh the value of the pin is 0 (pull down resistor), you push the button once, it changes to 1 and prints you pushed the button, then it keeps on doing that (meaning the value is jammed at 1 and saying you pushed the button when I did not.

To prove I wasn't losing my mind since at this point its stuck printing 1/button pushed even if you reset you have physically remove power from it to reset it. I hooked up an LED to the button, works like you would expect, push button, LED lights up, dont push button LED doesnt light up. Sometimes is screwed in the code.

Like I said I tried multiple pins and the LED (not onboard) proves the code is correct. The pico is just doing whatever it wants..

The Book's code:

from machine import Pin
from time import sleep

button = Pin(14, Pin.IN, Pin.PULL_DOWN)

# Setting up button as an input and setting it to pull down (default = 0 unpressed) so its not floating.
print(button.value())

while True:
    if button.value() == 1:
        print("You pressed the button!")
        sleep(2)

The output even after restarting your IDE

>>> %Run -c $EDITOR_CONTENT '`'

MPY: soft reboot
1
You pressed the button!
You pressed the button!
You pressed the button!
You pressed the button!
You pressed the button!
You pressed the button!
You pressed the button!

here's what it looks like if you yank the cord, notice it starts off as expected then its a runaway train..

>>> %Run -c $EDITOR_CONTENT '`'

MPY: soft reboot
0
You pressed the button!
You pressed the button!
You pressed the button!
You pressed the button!

Thoughts? I cant make it past the first simple program in the RPI beginner book! and I've programmed a lot in the past with Picos/MP.

[helgibbons]

@anglerfish27 I think you're experiencing the infamous RP2350-E9 latching pull-downs errata here - this is a silicon bug documented on page 1349 of the RP2350 datasheet.

We've been using the Pico's buit in pull-ups instead of pull-downs for our external button examples as a workaround, here's your code adjusted:

from machine import Pin
from time import sleep

button = Pin(14, Pin.IN, Pin.PULL_UP)

# Setting up button as an input and setting it to pull up (default = 1 unpressed) so its not floating.
print(button.value())

while True:
    if button.value() == 0:
        print("You pressed the button!")
        sleep(2)

Note the button logic is reversed here, as with pull-ups enabled on this GPIO pin it's reading 1 when unpushed and 0 when pushed.

[anglerfish27]

Thank you @helgibbons I guess its my fault for not reading 1300 pages of technical documentation :). Now this is not at a jab at you or Pimoroni in anyway let me be clear about that.

But what I'm hearing on page is RPI screwed up on their silicon. They give a work around instead of of fixing the silicon? Or perhaps they will quietly fix the issue in newer chips but folks like me are "stuck" with broken silicon, and yes I do consider this broken if they couldn't perform a simple button test to ensure the chip was working right with their pull up/downs, that's pretty concerning about quality control. So I'm just stuck with a buggy chip or will Rpi replace them as they SHOULD do? I know the answer..

Look I know I can work around the issue a 100 different ways but that's not the point. If Ford puts out a car where the gas pedal is reversed with the brake pedal I don't think they would just let that go and document it 1300 pages in a document most wont read. (I know my analogy is a bit extreme).

What bugs me the most (no pun intended) is what other known 'bug' am I going to hit later on when coding and I spend for ever trying to figure it out only to learn the chip is screwed up? I went the forums straight because I knew this was definitely a hardware issue, and I figured ok the firmware is still being worked on maybe its more buggy than I thought. But I did waste a good 30 minutes like an fool cursing at my breadboard. It wasn't until I did the LED test that "proved" the button worked that I came here. I dont want to be deep into a project to find out there's something wrong with some other core function. I guess Maybe I have to read 1300 pages of technical documentation.

This chip by Pimoroni has been THE chip I have been waiting for since I got into MCU's a few years back. I was like gosh if they could get some of this extra flash memory (I always bought the 16MB Picos) as pseudo RAM for loading up say a frame buffer for displaying images that would be GOLD along with WIFI if course. Here it is, FINALLY! Surprised honestly RPI didn't bother to put it out but at least they left the spots open in the hardware for vendors to do it. I had switched to the ESP32 chips because I could get up to 16MB of "RAM" to load huge images or download data, it was great, but I always missed my Pico where I first started. When the Pico W came out I was so excited looking for the RAM amount only to be sadly disappointed. Then after many ESP32 purchases, THIS chip came out! Pure bliss! I can't wait until all the bugs are ironed out looking forward to playing with Bluetooth and WIFI communication. Do we know if there will be an official port by Micropython.org for this Pico 2 W Plus? Since its kinda a Frankenstein board? Or will it be purely supported only by Pimoroni's dev team and the community. Hoping Adafruit decides to go this route too. Just because Lady Ada is a M.I.T. genius! Thank you for the 'workaround' good to keep in mind. Anymore bad silicon 'workarounds' I need to know about?

Cheers all!