RP2350 GPIO internal pull problem and simplistic workaround

Support
1

There’s a bit of fuss going on regarding GPIO pin problems on the RP2350 and I wanted to know if I’d basically bought a set of ‘brick’ boards or, as I suspected, is this actually a pretty specific issue which might not affect the casual/hobby user.

I tried to reproduce the now infamous RP2350 GPIO latching problem and I think I succeeded first time.

I just thought of the simplest scenario to use a pin with a pull down being fed with 3V3, so I used a push button wired to 3V3. I wouldn’t normally do that, I’d use a pull up and wire the push button to GND. Which, by the way, works perfectly on the RP2350.
[Just change the test to use a pull up on pin 1 and wire the push button to GND, of course then 1 is not pressed, 0 is pressed, you don’t need the output pin line at all.]

Here’s my micropython latch test:

from machine import Pin
import time

while True:
    but1=Pin(1,Pin.IN,Pin.PULL_DOWN)
    print(but1.value(), end="\b")
    time.sleep(0.1)
    #but1=Pin(1,Pin.OUT) #uncomment to get it working!

It shows the state of a push button wried to GPIO Pin 1 being set to 3V3 when the button is pressed.
If you try it, it’ll show 0 until you press the button, then it gets stuck and latched at 1, even when the button isn’t pressed.
If you uncomment the last line, it’ll all start working, zeroes and ones, just as you’d expect.

Am I being completely simplistic with unlatching the pin by reconfiguring it as an output and then again setting it as an input? It works for me.

As a side note I already successfully tried all the I2C GPIO pin SDA/SCL ‘pairs’ (except for pin 47, as it’s PSRAM chip select on the Pimoroni PGA2350 I’m using - I didn’t cut the trace). So there’s apparently no problem using I2C on the RP2350B (and my soldering skills are working for all the pins). I’m not sure if the I2C device itself has pull-up resistors, or if the pull-ups on the RP2350 pins are working correctly in this case.
I haven’t tried any SPI devices yet, I’m not sure about pull up/down requirements on SPI pins.

Analogue pins might have a problem, but I’m really not bothered about analogue values for my stuff. If I do need them, and it doesn’t work reliably, I’ll just use an I/O expander as a workaround.

Any thoughts, anyone?

2

The Errata in the data sheet has been updated and is now much more comprehensive!

https://datasheets.raspberrypi.com/rp23 … asheet.pdf

So using the internal pulldowns requires code modification as you are doing, so RP2350 is not a drop in replacement for RP2040.
It looks like I2C and SPI should be ok. Although I have not seen anyone report on very high speed SPI using PIO. For instance, 133Mhz+ QSPI to PSRAMs like Pimoroni’s Picovision does (which I would like conformation on as bought some Pimoroni RP2350 PGAs to try exactly this!).
If using PIO then I think you need to look as each individual application! For instance if trying to use the PIO as a logic analyser, this may be an issue depending on what was driving the input.

Regards

3

Oh, also the datasheet errata now states that Analogue inputs are OK as long as your clear the relevant GPIO input enable.

4

Thanks for the confirmation that, at least for what I need, I’m working around the issue as I should.

I saw the updated datasheet but, as usual, it’s datasheet speak. I’m not a professional hardware expert so often, in datasheets, it’s like they are talking in riddles about ‘exactly’ what to do. I’m not usually working with the C sdk, I take the easy way and let micropython handle the nitty-gritty for me.

I hope the purists who seem to have relied on a brand-new chip working exactly as they want as drop-in replacement for the RP2040, and then it just being ‘bigger, better, faster, more’, will get over it and accept they might need to mitigate a few issues in their products.

5

I have a dual display setup (SPI) that worked just fine with a Pico RP2040. Not so much when I swapped in a Pico 2 RP2350. I had to add 10k pull ups to the cs pins to get the second display to work. I’m not sure this is 100% related but I’m mentioning it anyway.

6

Thanks for that too.
It’s exactly the useful information needed to ‘make things work’ with the RP2350 just like with the RP2040, but not an exact, drop-in replacement.

1 Like
7

Regarding this giving issue with dual SPI displays and chip select (CS). I believe its only an issue when the GPIO is set as an input and with CS its and output. However I think that upon power up the pins as configured as input, so maybe there is an issue then and both displays think they are selected and that confuses them to extent that they wont work when the code gets running.

@alphanumeric are you able to reset the displays after code is running and see if they work without the pull-ups ? Also would lighter pull-ups work OK, like 100K ?

Regards

8

FYI

Pico Display 2.0 is working fine with the Pico Plus 2 and Micropython, but that is only one device (I think a ST7789) on the SPI bus!

9

The dual display issue is here.
Code runs fine from Thonny, but not as main.py - Support - Pimoroni Buccaneers

10

I tried to use a Pico2 in the Pico Explorer breadboard, and the buttons are permanently low using the standard pimoroni uf2 file.
I don’t think this is directly related to the pull down bug, because it needs pull-up. Maybe the changeover to the Pico2 isn’t yet complete on github so this doesn’t work :

button_a = Button(12)
if button_a.is_pressed:

Anyway - I got the buttons working by using the code from this thread, modified for the Explorer:

button_a=Pin(12,Pin.IN,Pin.PULL_UP)
etc for B, X and Y.
then test:
if not button_a.value():

11

I had a similar issue with a Pico 2 and the Pimoroni Display Pack V2.8. In my case it thought Button A was pressed / held down. Which jives with what your seeing.
@hel Hel Gibbons passed this code on a solution. It fixed it for me.
EDIT: Just realised its the same as what you posted, lol. it’s been one of those days. =)

from machine import Pin

button_a = Pin(12, Pin.IN, Pin.PULL_UP)
button_b = Pin(13, Pin.IN, Pin.PULL_UP)
button_x = Pin(14, Pin.IN, Pin.PULL_UP)
button_y = Pin(15, Pin.IN, Pin.PULL_UP)

if button_a.value() == 0:
    # etc etc
12

Floating CS pins on a SPI bus are always a potential problem once you have more than one device on the bus. The fact that this was “working” on the RP2040 was only good luck.

100K might also work, you will have to test. I went for 10K because some real experts suggested 10K.

I actually noticed the problem in one of my PCBs (display+sd-card on the bus). I added the pullups to the next version and everything is fine. As a workaround for the existing PCB I carefully fiddled around with internal pullups: pullup the second CS, initialize the first device (this takes control of the first CS), then release the second CS and then initialize the second device.