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
RP2350: PIO scripts fail, despite running on RP2040
Port, board and/or hardware
Pico 2
MicroPython version
MicroPython v1.25.0-preview.408.gf315a376b on 2025-03-26; Raspberry Pi Pico2 with RP2350
Reproduction
It has proved hard to produce a minimum repro, what follows is my best shot. The repro is quite fragile - minimal changes cause its behaviour to vary between working and failing.
Link GPIO numbers 1-18 and 2-17 and run the following:
import rp2
from machine import Pin, SPI
@rp2.asm_pio(autopush=True, autopull=True)
def spi_count():
out(x, 32)
wait(0, pins, 2) # CS/ True
label("loop")
jmp(pin, "good")
jmp(x_dec, "loop")
label("good")
in_(x, 32)
label("finish")
jmp("finish")
class Test:
def __init__(self, start_pin=0, sm_num=0):
self._sm1 = rp2.StateMachine(
sm_num,
spi_count,
in_base=start_pin,
jmp_pin=start_pin + 1,
)
self._sm1.active(1)
def go(self, cs, ck):
sm = self._sm1
sm.put(10_000_000)
cs(0) # Start
ck(1) # Stop
assert sm.rx_fifo(), "Rx fifo is empty."
print(sm.get())
cs = Pin(17, Pin.OUT, value=1)
ck = Pin(18, Pin.OUT, value=0)
t = Test()
t.go(cs, ck)
Expected behaviour
Result on RP2040 is to print a number around 9999759.
Observed behaviour
RP2350 produces an assertion fail. I assume that the RP2350 is failing to respond to the jump pin.
Additional Information
No, I've provided everything above.
Code of Conduct
Yes, I agree