# RP2350: Internal pull down issue

**URL:** <https://forums.pimoroni.com/t/rp2350-internal-pull-down-issue/25360>\
**Category:** Support\
**Created:** [August 27, 2024, 5:53am UTC](https://forums.pimoroni.com/t/rp2350-internal-pull-down-issue/25360 "2024-08-27T05:53:55Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![bobtrex](https://avatars.discourse-cdn.com/v4/letter/b/bc8723/32.png) [@bobtrex](https://forums.pimoroni.com/u/bobtrex)\
**Post date:** [August 27, 2024, 5:53am UTC](https://forums.pimoroni.com/t/rp2350-internal-pull-down-issue/25360/1 "2024-08-27T05:53:55Z")

</div>

If you are seeing some strange behavior using internal pull-down on the RP2350 boards using Micro-python or other be aware that that is a chip issue see

[https://forums.raspberrypi.com/viewtopic.php?t=375631](https://forums.raspberrypi.com/viewtopic.php?t=375631)

I though I was going mad. I dropped a Pico2 into a board I had made for the Pico. This is has 8 switches with pull-downs.

---

<div class="post-metadata">

**Author:** ![bobtrex](https://avatars.discourse-cdn.com/v4/letter/b/bc8723/32.png) [@bobtrex](https://forums.pimoroni.com/u/bobtrex)\
**Post date:** [August 27, 2024, 6:00am UTC](https://forums.pimoroni.com/t/rp2350-internal-pull-down-issue/25360/2 "2024-08-27T06:00:40Z")

</div>

BTW this is Errata 9 in the RP2350 data sheet!

---

<div class="post-metadata">

**Author:** ![ajay\_m](https://avatars.discourse-cdn.com/v4/letter/a/7cd45c/32.png) [@ajay\_m](https://forums.pimoroni.com/u/ajay_m)\
**Post date:** [August 27, 2024, 1:38pm UTC](https://forums.pimoroni.com/t/rp2350-internal-pull-down-issue/25360/3 "2024-08-27T13:38:00Z")

</div>

The problem appears to be far worse than defined by Errata 9. It’s not just pulldowns.

In particular it makes the ADC channels almost unuseable in some scenarios.  
This is what I have confirmed so far (and this has been reported by others as well)

1. Power cycle a board. Using any GPIO pin, observe that the pin is a high impedance and that applying VDD and releasing will not cause the pin to latch high (you may need to use a 1M resistor to ground afterward to be sure of clearing any floating gate charge)

2. Configure the pin in Micropython as an input but with a pullup. Observe that the pin now operates normally and if pulled to ground, reports 0 as the value, returning to 1 when signal is removed.

3. Configure the pin as an input but with NO pullup. Observe that if the pin is pulled to VDD it will latch at approximately 2.1V and remain at that voltage unless pulled down to zero.

This particularly affects scenarios like resistive touchscreens where you do not want either a pullup or a pulldown, and the spurious behaviour causes tracking errors due to the extra current sourced by the nominally high impedance input when it latches, which appears across the touchscreen resistance at that point.

It will also affect ADC applications where the source input impedance is significant as the pin will jump from 0 to 2.1V as the input signal changes, likely causing discontinuities in the tracked analogue signal.

It looks like the problem occurs when the pin is actually enabled, which will not be the case at power up. However I’m not clear the mitigation in E9 is going to help because if the pin behaves erroneously even for a short transient period of time as an analogue input, for instance, it’s going to cause significant errors on the ADC channels. In any case, you can’t currently apply the mitigation in Micropython or Circuitpython; changes to the underlying C code are required.

---

<div class="post-metadata">

**Author:** ![bobtrex](https://avatars.discourse-cdn.com/v4/letter/b/bc8723/32.png) [@bobtrex](https://forums.pimoroni.com/u/bobtrex)\
**Post date:** [August 27, 2024, 5:52pm UTC](https://forums.pimoroni.com/t/rp2350-internal-pull-down-issue/25360/4 "2024-08-27T17:52:22Z")

</div>

@ajay_m

Ouch, that’s even worse! Was hoping to use the improved ADC without the RP2040 ADC bug!!  
I am sure there will be lots of developers all over this and hopefully we will get full clarity, but it doesn’t look good! I see on the Raspberry PI froum (above) the “Bus Pirate Devs” are pausing production.

> We’re concerned enough that we pulled the next batch back from assembly. It’s been a long day of chasing this down and I need some time to think before poking it more. I will do some plain pin tests tomorrow to confirm what is reported here.

---

<div class="post-metadata">

**Author:** ![ajay\_m](https://avatars.discourse-cdn.com/v4/letter/a/7cd45c/32.png) [@ajay\_m](https://forums.pimoroni.com/u/ajay_m)\
**Post date:** [August 27, 2024, 7:50pm UTC](https://forums.pimoroni.com/t/rp2350-internal-pull-down-issue/25360/5 "2024-08-27T19:50:19Z")

</div>

Ok, I was partially wrong on this one. Yes, a pin enabled for input with no pullup or pulldown does latch, that’s definitely correct. However when you subsequently perform an ADC read, the pin transitions back to a high impedance state and then stays there. And you can perform ADC reads without ever configuring the pin. I had not realised that, because I had always passed a pin object to the ADC constructor, not realising it will alternatively just take a pin number.

Now I’m not sure if in that scenario there’s any kind of slew issue that would cause a transient ADC reading to be incorrect. Because of course the pin is reconfigured by the looks of it on the ADC read and was potentially latched at 2.1V before the ADC read cycle is initiated. Depending on the impedance and capacitance that is present at that time, it might take a finite time to discharge that away  
At present I still have the anomaly that my touchscreen tracking code is showing high ADC readings in the middle of the X axis, and these correlate to the pin latching high while configured as a digital input. (which it needs to be in the initial touch detection phase of the read).  
I was in the process of recording the voltages and resulting ADC values for each overlay button when I found the latching behaviour, but this may not be the root cause.  
My code, as I said, works perfectly on the RP2040. I understand that the RP2350 ADC is better so I wouldn’t expect the kind of non-linearity I’m seeing here - I’ll have to do further research.

---

<div class="post-metadata">

**Author:** ![ajay\_m](https://avatars.discourse-cdn.com/v4/letter/a/7cd45c/32.png) [@ajay\_m](https://forums.pimoroni.com/u/ajay_m)\
**Post date:** [September 3, 2024, 7:25pm UTC](https://forums.pimoroni.com/t/rp2350-internal-pull-down-issue/25360/6 "2024-09-03T19:25:00Z")

</div>

The non linearity is caused by setting ISO when resetting the pin to a high impedance state. It is necessary only to set input enabled to 0. When this is done adc behaviour is correct. I have no explanation for this behaviour but there you are.

---

<div class="post-metadata">

**Author:** ![notherbert](https://avatars.discourse-cdn.com/v4/letter/n/a5b964/32.png) [@notherbert](https://forums.pimoroni.com/u/notherbert)\
**Post date:** [September 27, 2026, 2:34pm UTC](https://forums.pimoroni.com/t/rp2350-internal-pull-down-issue/25360/7 "2026-09-27T14:34:12Z")

</div>

Two years later … has this been fixed and how would I determine if a given Pico has the glitch without resorting to testing it? Is the machine ID encoded with the manufacture date, e.g.?

---

<div class="post-metadata">

**Author:** ![hel](https://sea2.discourse-cdn.com/flex016/user_avatar/forums.pimoroni.com/hel/32/6075_2.png) [@hel](https://forums.pimoroni.com/u/hel)\
**Post date:** [September 28, 2026, 12:33pm UTC](https://forums.pimoroni.com/t/rp2350-internal-pull-down-issue/25360/8 "2026-09-28T12:33:40Z")

</div>

Assuming you can see the RP2350 chip, there’s a printed serial number that will let identify whether it’s an A2 (affected by the E9 errata issue) or A4 (latest revision) chip.

Sounds like it’s also possible to use `picotool` to identify the chip revision whilst the board’s in DFU/bootloader mode, though that’s not something I’ve tried myself: [https://forums.raspberrypi.com/viewtopic.php?t=398229](https://forums.raspberrypi.com/viewtopic.php?t=398229)
