RP2350: "stuck at 2V" input pin behavior
Port, board and/or hardware
Pimoroni Tiny2350
MicroPython version
Using build from https://github.com/pimoroni/pimoroni-pico-rp2350
https://github.com/pimoroni/pimoroni-pico-rp2350/releases/download/v0.0.5/tiny2350-v0.0.5-pimoroni-micropython.uf2
Reproduction
I have been debugging what seems to be a problem in CircuitPython which seems related to the discussion here: https://github.com/orgs/micropython/discussions/15621#discussioncomment-10423602
It appears related to RP2350-E9 in the RP2350 datasheet, but am seeing even stranger behavior that seems more pervasive than RP2350-E9. The "stuck high" behavior described in the erratum seems to be reproducible even without enabling the internal pulldown:
Testing on a Pimoroni Tiny 2350:
>>> from machine import Pin
>>> gp0 = Pin(0, mode=Pin.IN, pull=None)
>>> gp0.value() # initial value of unconnected pin
0
>>> gp0.value() # attach 1M resistor from pin to 3.3V
1
>>> gp0.value() # remove resistor
1
>>> gp0.value() # jumper pin to ground with 1M resistor
1
A voltmeter on the pin shows a stable 2.3V even after many seconds. The pin appears to be latched to 2.3V, as the erratum describes. Jumpering the pin hard (0 ohms) to ground and then removing the jumper restores the quiescent pin voltage to 0v and gp0.value() again shows 0.
I first saw this behavior in CircuitPython and reproduced it in MicroPython as well.
I don't see similar "stuck" behavior on RP2040.
One consideration: the hard-reset state of the pin has the pull-down set. But I have been modifying the CircuitPython code to clear the pull-downs before the pin is set up for input, and that did not help.
I opened an issue with raspberrypi: https://github.com/raspberrypi/pico-feedback/issues/401
Expected behaviour
see above
Observed behaviour
see above
Additional Information
No, I've provided everything above.
Code of Conduct
Yes, I agree
RP2040, RP2350 PIO: anomalous behaviour of jump pin
Port, board and/or hardware
Pico and Pico 2 (RP2040, RP2350)
MicroPython version
MicroPython v1.26.1 on 2025-09-11; Raspberry Pi Pico with RP2040
RP2350 tests also use release build 1.26.1
Reproduction
Link GPIO 1-17, attach a scope/LA to GPIO 2, and run the following:
from machine import Pin, PWM
import rp2
import time
inp = Pin(0, Pin.IN)
jmp = Pin(1, Pin.IN)
opp = Pin(2, Pin.OUT, value=1)
pwm = PWM(Pin(17)) # Link GPIO 17 to GPIO 1
pwm.freq(1000)
pwm.duty_u16(0xFFFF // 2)
@rp2.asm_pio(out_init=rp2.PIO.OUT_LOW) # Fails to run at all if arg is omitted (RP2040 & RP2350)
def sm_test():
set(x, 0)
wrap_target()
wait(0, pins, 1) # Wait for GPIO 1 to go low
mov(osr, x) # Ouput==0 while input==0
out(pins, 1)
label("loop") # Loop until jump pin goes high
jmp(pin, "pulse")
jmp("loop")
label("pulse")
mov(osr, invert(x)) # Emit a pulse
out(pins, 1)
mov(osr, x)
out(pins, 1)
wrap()
sm0 = rp2.StateMachine(0, sm_test, freq=100_000, out_base=opp , in_base=inp, jmp_pin=jmp)
sm0.restart()
sm0.active(1)
while True:
time.sleep(1)
print("Running")
Expected behaviour
Expected to output a single pulse on GPIO 2 after every positive going edge of GPIO 17.
Observed behaviour
As expected on RP2040. On RP2350 it behaves as if the jump pin were always active with pulses appearing throughout the low period. This behaviour continues if the jump pin is assigned to another GPIO which is strapped low.
On RP2350 and RP2040 if the decorator arg is omitted, no output appears. This seems surprising: if not a bug the requirement should be documented.
Additional Information
No, I've provided everything above.
Code of Conduct
Yes, I agree