Raspberry Pi Pico 2

[shariltumin]

The Raspberry Pi Pico 2 is on its way! The first shipment is scheduled for August 19, 2024.

It's built on the RP2350 microcontroller with a higher core clock speed, double the on-chip SRAM, double the on-board flash memory, and more powerful Arm cores.

I'm pretty sure it'll run MicroPython right away.

[jkorte-dev]

There are builds available for download even for the RISCV version ?!?

https://www.micropython.org/download/RPI_PICO2/

but the link to the repo is invalid.
I wish I had a RP2350 to test the micropython build

[peterhinch]

See #15619.

From a quick look it seems to offer higher clock speeds, hardware FP, and PSRAM support among other goodies. See datasheet.

[GitHubsSilverBullet]

It could be a first step towards a royalty-free and open-source architecture.
And one can run both architectures at the same time (one Arm core, one RISC-V core).
Quite nice for an evaluation.

[rkompass]

Would be crazy if MP could run both simultaneously. Which I do not expext tbh.

[beyonlo]

@rkompass On the pico 1 (that has two cores as well) MP runs in both cores simultaneously. So I think that in pico 2 will run in the same way.

[rkompass]

Thanks. I did some reading/thinking: No chance for mixed architecture mode unless you would devise a special binary with doubled/mixed code for all functionality.

Rather another question appears: Why use the RISC-V core at all, if the Armv8 has everything (including FP) and with a 3-staged pipeline is also quite fast. We will see...

[beyonlo]

Run two ARM cores simultaneously on the MP - works.
Run two RISC-V cores simultaneously on the MP - works
Run one RISC-V core and one ARM core simultaneously on the MP - I do not know if it works, and if works, as you wrote, maybe needs a special binary with doubled/mixed code for all functionality. But I can't see some advantage to use one core of ARM and another core of RISC-V simultaneously.

About your second question, I have the same question. I see only two advantages with the option to use RISC-V instead ARM:

• I am not sure about this (I didn't research it yet), but I think that RISC-V azard3 safe more energy than ARM M33, so it can be fit better for low power applications/battery applications.
• People already can to test the new free arch RISC-V as feedback for new RISC-V microprocessors development on the raspberry pi.

I also would like to know the advantages to use the RISC-V over ARM M33 on the RP2350.

[rkompass]

@mendenm : The faster more new and better architectures will appear the stronger the paradoxical effects of fragmentation of developer ressources will become. This may be even more of an issue with MP as we seem to have the bottleneck that developments have to go through @dpgeorge 's support/approval.

[shariltumin]

I hope that core MicroPython will prevail. It might be difficult when people expect software to be free but are willing to pay for hardware.

I hope MicroPython will continue to evolve and support newer interesting MCUs that are yet to come.

Maybe there will be more "special" versions for different hardware platform vendors in the future, targeting different market segments.

[obdevel]

They were rationed to one per customer yesterday at the RPi retail store here in Cambridge, UK.

MicroPython v1.24.0-preview.201.g269a0e0e1 on 2024-08-09; Raspberry Pi Pico2 with RP2350
Type "help()" for more information.
>>> 
MicroPython v1.24.0-preview.201.g269a0e0e1 on 2024-08-09; Raspberry Pi Pico2 with RP2350
Type "help()" for more information.
>>> import micropython
>>> dir(micropython)
['__class__', '__name__', 'const', '__dict__', 'alloc_emergency_exception_buf', 'heap_lock', 'heap_unlock', 'kbd_intr', 'mem_info', 'opt_level', 'qstr_info', 'schedule', 'stack_use']
>>> micropython.mem_info()
stack: 452 out of 12032
GC: total: 486848, used: 17920, free: 468928
 No. of 1-blocks: 251, 2-blocks: 46, max blk sz: 64, max free sz: 29295
>>> 
>>> import gc
>>> dir(gc)
['__class__', '__name__', '__dict__', 'collect', 'disable', 'enable', 'isenabled', 'mem_alloc', 'mem_free', 'threshold']
>>> gc.collect()
>>> gc.mem_free()
479488

[shariltumin]

Good to hear. Which firmware have you tried, ARM or RISC-V?

If you've tried both, did you notice any differences (in your opinion)?

[obdevel]

Based on initial testing, my current codebase just works on both. It uses a pretty broad range of micropython (SPI, GPIO, timers, interrupts, lots of async) but is not performance critical so I can't really say much about that. RISC-V 'feels' a little less responsive at the REPL but I haven't done any formal analysis and that is probably to be expected.

MPY: soft reboot
MicroPython v1.24.0-preview.201.g269a0e0e1 on 2024-08-09; Raspberry Pi Pico2 with RP2350-RISCV
Type "help()" for more information.
>>> 
>>> import gc
>>> gc.collect()
>>> gc.mem_free()
461952
>>> 

[scruss]

Looks like there might be a slight difference in USB CDC handling: a user is reporting a complete loss of enumerated serial port if their code doesn't include an occasional print() — Pico 2 Micropython problem - Raspberry Pi Forums

[tonygo]

Hi I'm the guy with the problem.
I'm most concerned that the execution just stops without an error message having lost connection to the Shell. Changing the loop values made no difference - it still crashes.
I know I'm using a VERY early version of the Pico 2 UF2 and hope a fix it is not too difficult.

[tonygo]

`

Colour Mixing Routine

def colour(R,G,B): # Compact method!
mix1 = ((R&0xF8)*256) + ((G&0xFC)*8) + ((B&0xF8)>>3)
return (mix1 & 0xFF) *256 + int((mix1 & 0xFF00) /256) # low nibble first

==== Main ====

pwm = PWM(Pin(BL))
pwm.freq(1000)
pwm.duty_u16(32768)#max 65535

LCD = LCD_1inch3()

LCD.fill(LCD.WHITE)
LCD.show()
'''

Set up buttons

key0 = Pin(15,Pin.IN,Pin.PULL_UP)
key1 = Pin(17,Pin.IN,Pin.PULL_UP)
key2 = Pin(2 ,Pin.IN,Pin.PULL_UP)
key3 = Pin(3 ,Pin.IN,Pin.PULL_UP)
'''
centre_x =int(LCD.width/2)
centre_y = int(LCD.height/2)
R = int((LCD.width + LCD.height)/4)
r = int((LCD.width + LCD.height)/8)
LCD.fill(0)
LCD.show()

LCD.ellipse(centre_x, centre_y,R,r,colour(255,255,0),1)
LCD.show()
LCD.ellipse(centre_x, centre_y,r,r,colour(0,0,255))
LCD.show()

for i in range(r, 1, -1):

LCD.ellipse(centre_x, centre_y,i+1, i+1,colour(i*5,i*3,i*4), 1)
LCD.show()
time.sleep(0.1)

time.sleep(1)
LCD.fill(0)
LCD.show()

gc.collect
print()
print(gc.mem_free())
`
If I comment out the section setting up the keys it does not crash and works as expected to the end of the program.
This is very strange.

[tonygo]

I've just tested the program, including the button key setup code, on a Pimoroni Lipo and it works without crashing.
I used the same display and code, just swapped over from Pico 2 to Pico Lipo as this is a simple plug in display.

I'm expecting a Pimoroni Pico Plus 2 in the post today and will test with that when it arrives, and report back.

[tonygo]

My Pico Plus 2 has arrived and using the same UF2 it falls over in the same manner.

[rkompass]

Just saw this Video, which is from Circuitpythons perspective, but gives a lot of insights into the RP2350.
I found the part about HSTX especially interesting. With the larger RAM and HSTX a video signal for DVI can be generated from a framebuffer memory (e.g. about 300K for 640x480 resolution and 332 RGB 8 bit color coding), without usage of either CPU.
Circuitpython btw. at present only supports the ARM processors, due to their build system.

[peterhinch]

A benchmark for the ARM version: a 1024 point DFT in Arm Thumb assembler from this library, running dfttest.bench().

• Pico 2: 6.968ms
• Pyboard 1.1: 12.9ms
• Pyboard D SF2W and SF6W: 3.6ms

Note this cannot be run on Pico 1 or on the Risc V core (the Pico 1 is Arm V6 without hardware FP).

For anyone wanting a benchmark which should be adaptable for all targets, see the official pystone test.

[shariltumin]

So Pico2 is better than Cray1.

[peterhinch]

It's rather cheaper and uses less power :)

[peterhinch]

Incidentally I ran the official benchmark (e.g.)

$ ./run-perfbench.py 100 100 -d /dev/ttyACM0

on several targets but I don't think it's designed for comparing targets - rather its aim is comparing firmware builds on the same target. The results seem to be highly normalised with Pyboard 1.1 and Pyboard D SF6W showing rather similar values (the 3rd column is a measure of speed).

[rkompass]

Did a comparison of crc32 processing (this lib) with bytecode and viper:

• Pico2 (150 MHz), Arm:
  bytecode: 26.4µs per byte
  viper: 0.35µs per byte

• Pico2 (150MHz), Risc:
  bytecode: 24.5µs per byte
  viper: 0.27µs per byte

• Pico (125MHz):
  bytecode: 59.2µs per byte
  viper: 0.48µs per byte

• Pyboard 1.1 (168MHz):
  bytecode: 42.2µs per byte
  viper: 0.47µs per byte

It seems @agatti did a very good job at implementing the viper for Risc, as it is 30% faster.

[agatti]

Well, thanks :) Still, those result you've got are quite interesting indeed, I'd have expected Arm to be on par with RV32 when it comes to viper.

The main difference in viper implementations for table-heavy code like the one you tested is that for load/store operations involving an immediate offset RV32 has more chances to use a single opcode[1], whilst when it's a register RV32 has to rescale the offset coming in from the runtime as it must be expressed in bytes (and it is stored as halfword/word offsets in the source register).

[1]: RV32's range for those opcodes is usually a couple of orders of magnitude larger.

[mendenm]

I was thinking this was similar to a mini-supercomputer accelerator box we got for a Vax at Caltech, circa 1984. I think it cost somewhat more than $5. :-)

…

On Aug 17, 2024, at 7:26 AM, shariltumin ***@***.***> wrote: So Pico2 is better than Cray1. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: ***@***.***>

[ayjaym]

I'm having difficulty dropping a Pico Pi 2 into a project that's working with the original Pico. For example this WS2812 code doesn't work properly on the Pico 2 - the LEDs flash and flicker, but it works fine on a Pico and Pico W dropped into the project

# Example using PIO to drive a set of WS2812 LEDs.

import array, time
from machine import Pin
import rp2

# Configure the number of WS2812 LEDs.
NUM_LEDS = 137
PIN_NUM = 2
brightness = .1



@rp2.asm_pio(sideset_init=rp2.PIO.OUT_LOW, out_shiftdir=rp2.PIO.SHIFT_LEFT, autopull=True, pull_thresh=24)
def ws2812():
    T1 = 2
    T2 = 5
    T3 = 3
    wrap_target()
    label("bitloop")
    out(x, 1)               .side(0)    [T3 - 1]
    jmp(not_x, "do_zero")   .side(1)    [T1 - 1]
    jmp("bitloop")          .side(1)    [T2 - 1]
    label("do_zero")
    nop()                   .side(0)    [T2 - 1]
    wrap()


# Create the StateMachine with the ws2812 program, outputting on pin
sm = rp2.StateMachine(0, ws2812, freq=8_000_000, sideset_base=Pin(PIN_NUM))

# Start the StateMachine, it will wait for data on its FIFO.
sm.active(1)

# Display a pattern on the LEDs via an array of LED RGB values.
ar = array.array("I", [0 for _ in range(NUM_LEDS)])

##########################################################################
def pixels_show():
    dimmer_ar = array.array("I", [0 for _ in range(NUM_LEDS)])
    for i,c in enumerate(ar):
        r = int(((c >> 8) & 0xFF) * brightness)
        g = int(((c >> 16) & 0xFF) * brightness)
        b = int((c & 0xFF) * brightness)
        dimmer_ar[i] = (g<<16) + (r<<8) + b
    sm.put(dimmer_ar, 8)
    time.sleep_ms(10)

def pixels_set(i, color):
    ar[i] = (color[1]<<16) + (color[0]<<8) + color[2]

def pixels_fill(color):
    for i in range(len(ar)):
        pixels_set(i, color)

def color_chase(color, wait):
    for i in range(NUM_LEDS):
        pixels_set(i, color)
        time.sleep(wait)
        pixels_show()
    time.sleep(0.2)
 
def wheel(pos):
    # Input a value 0 to 255 to get a color value.
    # The colours are a transition r - g - b - back to r.
    if pos < 0 or pos > 255:
        return (0, 0, 0)
    if pos < 85:
        return (255 - pos * 3, pos * 3, 0)
    if pos < 170:
        pos -= 85
        return (0, 255 - pos * 3, pos * 3)
    pos -= 170
    return (pos * 3, 0, 255 - pos * 3)
 
 
def rainbow_cycle(wait):
    for j in range(255):
        for i in range(NUM_LEDS):
            rc_index = (i * 256 // NUM_LEDS) + j
            pixels_set(i, wheel(rc_index & 255))
        pixels_show()
        time.sleep(wait)

BLACK = (0, 0, 0)
RED = (255, 0, 0)
YELLOW = (255, 150, 0)
GREEN = (0, 255, 0)
CYAN = (0, 255, 255)
BLUE = (0, 0, 255)
PURPLE = (180, 0, 255)
WHITE = (255, 255, 255)
COLORS = (BLACK, RED, YELLOW, GREEN, CYAN, BLUE, PURPLE, WHITE)

print("fills")
pixels_set(0,GREEN)
pixels_set(1,RED)
pixels_set(2,BLUE)
pixels_set(3,GREEN)

pixels_set(8,GREEN)
pixels_set(9,RED)
pixels_set(10,BLACK)
pixels_set(11,GREEN)

pixels_set(16,GREEN)
pixels_set(17,RED)
pixels_set(18,BLUE)
pixels_set(19,GREEN)

pixels_fill(PURPLE)
pixels_show()
#for color in COLORS:       
#    pixels_fill(color)
#    pixels_show()
#    time.sleep(0.2)

#print("chases")
#for color in COLORS:       
#    color_chase(color, 0.01)

#print("rainbow")
rainbow_cycle(0)

[GitHubsSilverBullet]

Create the StateMachine with the ws2812 program, outputting on pin

sm = rp2.StateMachine(0, ws2812, freq=8_000_000, sideset_base=Pin(PIN_NUM))

8MHZ == 125ns period.
Given the fact that a WS2812 wants to have 850/400ns and 450/800ns, that entire undertaking uses a wrong frequency.

A much better frequency would be 1/50ns ie. 20MHz. Then you'd have 17/8 and 9/16 cycles and control the LED properly.

[ayjaym]

Thanks very much for the kind response. To be honest, I am not the author of that code and didn't cross check those issues - it must be marginal and work almost by accident on the RP2040 in that case if we're that far away from the timing specs. I do have a proper Siglent scope so I can always probe out the signal and also make the change you suggest, and see how that works. On Sunday, 18 August 2024 at 19:12:06 BST, Norbert ***@***.***> wrote: Create the StateMachine with the ws2812 program, outputting on pin sm = rp2.StateMachine(0, ws2812, freq=8_000_000, sideset_base=Pin(PIN_NUM)) 8MHZ == 125ns period. Given the fact that a WS2812 wants to have 850/400ns and 450/800ns, that entire undertaking uses a wrong frequency. A much better frequency would be 1/50ns ie. 20MHz. Then you'd have 17/8 and 9/16 cycles and control the LED properly. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: ***@***.***>

[ayjaym]

Ok well in fact it looks like a hardware issue. After adding a pile of bypass caps around the power rails in the project I can virtually - but not totally -eliminate the issue. At this point I decided to get more scientific. I put a Pico and Pico 2 on two separate breadboards and wired up a short chain of WS2812 tape with 14 LEDs on each chain to the two devices, using GPIO2 as the output. The code then does a white fill and loops.
I then connected these up to power and monitored the signals with my Siglent 200MHz dual-channel scope.
Now on both devices the PIO code creates an 876ns high and 376ns low pulse which I think is reasonably within tolerance. This code is actually from the ws2812_rp2 module which is very widely used. The library introduces a very significant reset time in the order of milliseconds and this is the same on both devices, certainly well in excess of the minimum as far as I can determine.
I could not identify any difference in pulse amplitude, rise and fall times or ringing (well, there is a little more ringing with the RP2040 but that's all I could see)

BUT

The RP2350 is much more sensitive to capacitance on the signal line. Merely touching the end of the WS2812 strip would introduce flickering and setting the scope probe to X1 on the Pico 2 immediately caused the issue. Whereas the RP2040 was completely immune to the problem. I think typically in X1, the probe has a loading of 1M in parallel with 20pF or so capacitance. You can see that rise and fall times are degraded on both devices but the pulses look exactly the same, however I have not tried setting any of the more sophisticated triggering modes to try and see if I can capture the specific issue.
I believe the pad analogue circuitry is different in the 2350 (after all, errata 9, which doesn't apply to the 2040) and it looks like for WS2812 applications it would extremely prudent to interpose a driver, if nothing else, to push the full 5V signal swing into the WS2812 chain, since the GPIOs are obviously only swinging 3.3V.
I would have expected to see a more obvious signal difference between the two devices but there may be some noise issues that are not going to show up as clearly, I need to capture a longer trace and zoom in, which I can do with the Siglent.

[rkompass]

From the datasheet (2350):

Output drive strength can be set to 2mA, 4mA, 8mA or 12mA

Did you check that both Picos are set to use the same output drive strength?

[ayjaym]

Ok, looks like Errata 9 in the processor datasheet might be a real problem here.

If I set a pin to input mode with a pulldown e.g
a = Pin(28, mode=Pin.IN, pull=Pin.PULL_DOWN)
then initially a.value() will correctly return 0.
If the pin is driven to VDD and then the input source goes high impedance (which is the case for the resistive touchscreen I'm using) then the pin voltage drops back to about 2.1V, causing a subsequent read to report 1 instead of the expected 0

Errata 9 states

This issue presents under the following conditions, for any GPIO 0 through 47:

1. Pull-down resistor is enabled in GPIO0.PDE
2. Pull-up resistor is disabled in GPIO0.PUE
3. Input buffer is enabled in GPIO0.IE
4. Output buffer is disabled (e.g. selecting the NULL GPIO function)
5. Isolation is clear in GPIO0.ISO, or the previous were true at the point isolation was set
6. Input is driven externally to IOVDD, and then released
   When all of the above conditions are met, the pad level is at around 2.1 to 2.2 V (for IOVDD of 3.3 V)
   rather than being pulled to ground. This is caused by a fault in the analogue circuitry of the pad itself

and the mitigation states

When pull-down behaviour is required, clear the pad input enable in GPIO0.IE (for GPIOs 0 through 47) to
ensure that only the pull-down resistor is enabled.
To read the state of a pulled-down GPIO from software, enable the input buffer by setting GPIO0.IE
immediately before reading, and then re-disable immediately afterwards. Note that if the pad is already a
logic-0, re-enabling the input does not disturb the pull-down state

However I'm not sure how to apply this mitigation in Micropython - I can switch the pin between IN and OUT mode but once this problem occurs, I can't find a way of resetting the pin behaviour reliably.

[peterhinch]

I think this should be raised as a MicroPython issue. The mitigation will involve changing the C code. A possible workround for your project might be to add an external pull-down resistor. Whether this will work depends on the impedances involved.

[GitHubsSilverBullet]

However I'm not sure how to apply this mitigation in Micropython - I can switch the pin between IN and OUT mode but once this problem occurs, I can't find a way of resetting the pin behaviour reliably.

That's a one-liner.
mem32[] … PADS_BANK0_BASE … GPIOx

[ayjaym]

Where should I raise this issue, do you think?. The test case is very simple.

Using the following code

from machine import Pin
a = Pin(28, mode=Pin.IN, pull=Pin.PULL_DOWN)
print(a.value())

Run the code, observe that value is 0 (expected)

Connect 6K8 resistor between pin 28 and VDD (3.3V)

Run the code, observe that value is 1 (expected)

Remove the resistor

Run the code. Observe that value is 1 (error) instead of 0 (Pico 1)

Discovered this in a Pico 1 project where I was curious as to how much of a 'drop in' replacement the Pico 2 would be. The huge advantage of the Pico is that it can read resistive touchscreens without any additional hardware. The code relies on dynamically reconfiguring four GPIO lines, two of which are ADC pins. Unfortunately pulldown resistors can't be used because even a high pulldown significantly compromises the linearity of the result.

To read the touchscreen we start in 'touch mode' where X- and Y- are connected to the ADC channels but these are configured as standard inputs, with X- set to have a pulldown and Y- set to high impedance. We then configure X+ to send logic 1 as an output and Y+ to high impedance.

When the user touches the screen X- will transition to logic 1. This gives us a clean 'start touch' signal. If you rely on just reading an analogue value always, you hit the problem that the initial touch leading edge is quite ragged when fed into a high impedance input. This way you won't get logic 1 until the signal has already gotten out of the noise.

You then dynamically reconfigure the GPIOs to perform an analogue read on X and Y by configuring the pins appropriately, once for X and once for Y. In this mode you enable the ADC channels as required, then do some signal processing to average out noise and look for any glitches i.e signal that's more than a standard deviation out from the average, and reject the touch if you do.

But during the analogue read phase any pulldown will compromise linearity because the touchscreen impedance is several hundred ohms and even a 50K pulldown introduces issues, when you are reading touchpoints (via a button overlay) where the buttons are only about 5mm apart. At this distance you have approximately a difference of 10 in raw analogue values between adjacent buttons.

This all works brilliantly on the Pico 1 of course.

[peterhinch]

Raise the issue against MicroPython. Identify RP2350 in the title and include a reference to errata 9 in the text along with the repro you've identified above.

[ayjaym]

Its much worse than that, by the looks of it. Looks like the issue has already been raised and further behavioural anomalies have surfaced. I spent hours trying to track down why I was seeing odd anomalies with the ADC performance when tracking the touch screen but only with the RP2350 - the code had worked perfectly with the 2040. At first I thought it was electrical noise but eventually it occurred to me to put my DVM across the actual ADC input.
What I found - and others have seen this too - is that an input configured with NO pullup or pulldown resistor is ALSO exhibiting anomalous behaviour. So with the touchscreen when I read the screen, if the resulting input level to the ADC pin exceeds logic 0 threshold, the pin 'latches up' to logic 1 and then stays there until it gets pulled down to logic 0 by touching at a lower X/Y axis value. This causes an anomalous extra current to flow so that touches beyond that point see an extra current into the resistance of the touchscreen that cause the resulting values to be higher than they should be. I've wasted hours tracking this down.

Currently it looks like GPIO to the 2350 is irremediably borked. This is very unfortunate. Hopefully some kind of software fix is possible but as others have said, Errata 9 is actually far worse than it originally looked.

[badgermedia]

Is there a rough idea of timeline yet for MP support on the RP235x family please?

[robert-hh]

The Pico 2 board carries a RP2350. Besides a specific adaption for Pin labels, the provided firmware should work on any RP2350 board. It will get a 1.24.0 Release firmware when this release is published for all boards. Until then there will be preview versions.

[badgermedia]

Thanks Robert. Is there a timescale for 1.24?

[robert-hh]

I do not know it. But you can safely use the preview versions.

[mattytrentini]

The v1.24 release has been delayed - mostly due to the RP2350 release I imagine. You can track the progress of the tickets gating the release here:

https://github.com/micropython/micropython/milestone/7

There is still quite a lot left to do - and maybe some features will have to be postponed in order to ship. Please comment on tickets if you feel strongly about them, it can help prioritise them!

[badgermedia]

Thanks for the update. Hopefully there will be a full and stable release for the RP2350 soon, as MP is highly advertised on the Raspberry Pi site. I'm looking forward to the versions with internal flash storage as well - will no longer need to look at STM.

[shariltumin]

I have problem getting RP2350 to pass "tests/ports/rp2/rp2_lightsleep.py" on ARM firmware

>>> import rp2_lightsleep
abcdfghijklmnopijklmnopqstuvxyzabcdefghiMPY: soft reboot
MicroPython v1.24.0-preview.203.gb9f6698d3.dirty on 2024-08-23; Raspberry Pi Pico2 with RP2350

I have no such problem with RISC-V firmware.

>>> import rp2_lightsleep
abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuv
DONE
>>> 
MPY: soft reboot
MicroPython v1.24.0-preview.203.gb9f6698d3.dirty on 2024-08-23; Raspberry Pi Pico2 with RP2350-RISCV

[ayjaym]

Will do. Switching the logic to use a pull up works in this case so I have done that. Will then work for both versions of the Pico.  Yahoo Mail: Search, organise, conquer On Sun, 25 Aug 2024 at 12:06, Peter ***@***.***> wrote: Raise the issue against MicroPython. Identify RP2350 in the title and include a reference to errata 9 in the text along with the repro you've identified above. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: ***@***.***>

[dhalbert]

I have been debugging what seems to be a related problem in CircuitPython, and am seeing even stranger behavior that seems more pervasive than RP2350-E9. The "stuck high" behavior 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.

[ayjaym]

I've replied earlier in this thread but I am also seeing this behaviour. A pin configured as input with no pullup or pulldown will latch into logic 0 or 1 if a signal is applied and then removed (i.e with pin now disconnected). But in fact the pin has latched to logic 0 or 1 and will now not be a high impedance at all. This causes severe ADC problems with a touch screen which is how I first saw the issue.

[ayjaym]

I believe the only configuration not to display anomalous behaviour is an input with a pullup. This seems to function correctly when pulled down and then released to a disconnected state.

[shariltumin]

There is an article on hackster.io, https://www.hackster.io/news/a-surprise-hardware-bug-in-raspberry-pi-s-rp2350-leads-to-unexpected-pull-down-behavior-76b51ec22ede about this GPIO "latching" problem.

[dhalbert]

Also there's this discussion in the RPi Forums: https://forums.raspberrypi.com/viewtopic.php?t=375631

[ayjaym]

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. At the point that the ADC read is initiated, the pin was configured as a digital input and will potentially be latched. Depending on the impedance and capacitance that is present at that time, it might take a finite time to discharge that away. It's looking back into the touchscreen which represents probably a few hundred ohms of impedance but probably quite a bit of capacitance.
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.

[GitHubsSilverBullet]

Just received mine and I have to say: That chip seems to be a complete loss.
First impressions and tests suggest that when a latch-up occurs, only a reset using bit 9 on the RESETS_BASE will recover (or a hardware reset)
Of course further tests in the morrow are needed, but to call all this a disappointment would be the understatement of the year.
Quick and ugly test:

#!micropython

from machine import Pin, mem32 as M
from time import sleep_ms

RESETS_BASE = const(0x40020000)
def PadReset():
    M[RESETS_BASE] |=  (1<<9)   # PADS_BANK0
    M[RESETS_BASE] &= ~(1<<9)   # PADS_BANK0

def Show():
    print(f'({p.value()}) {p}', end='   ')

PadReset()
for n in range(5):
    print(f'{n:2}', end='   ')

    p = Pin(0, Pin.IN, Pin.PULL_DOWN)
    Show()
    p = Pin(0, Pin.IN, None)
    Show()
    p = Pin(0, Pin.IN, Pin.PULL_UP)
    Show()
    p = Pin(0, Pin.IN, None)
    Show()
    print()
    sleep_ms(500)
print()

for n in range(5):
    print(f'{n:2}', end='   ')
    PadReset()
    p = Pin(0, Pin.IN, Pin.PULL_DOWN)
    Show()
    p = Pin(0, Pin.IN, None)
    Show()
    p = Pin(0, Pin.IN, Pin.PULL_UP)
    Show()
    p = Pin(0, Pin.IN, None)
    Show()
    print()
    sleep_ms(500)

resulting in:

 0   (0) Pin(GPIO0, mode=IN, pull=PULL_DOWN)   (0) Pin(GPIO0, mode=IN)   (1) Pin(GPIO0, mode=IN, pull=PULL_UP)   (1) Pin(GPIO0, mode=IN)   
 1   (1) Pin(GPIO0, mode=IN, pull=PULL_DOWN)   (1) Pin(GPIO0, mode=IN)   (1) Pin(GPIO0, mode=IN, pull=PULL_UP)   (1) Pin(GPIO0, mode=IN)   
 2   (1) Pin(GPIO0, mode=IN, pull=PULL_DOWN)   (1) Pin(GPIO0, mode=IN)   (1) Pin(GPIO0, mode=IN, pull=PULL_UP)   (1) Pin(GPIO0, mode=IN)   
 3   (1) Pin(GPIO0, mode=IN, pull=PULL_DOWN)   (1) Pin(GPIO0, mode=IN)   (1) Pin(GPIO0, mode=IN, pull=PULL_UP)   (1) Pin(GPIO0, mode=IN)   
 4   (1) Pin(GPIO0, mode=IN, pull=PULL_DOWN)   (1) Pin(GPIO0, mode=IN)   (1) Pin(GPIO0, mode=IN, pull=PULL_UP)   (1) Pin(GPIO0, mode=IN)   

 0   (0) Pin(GPIO0, mode=IN, pull=PULL_DOWN)   (0) Pin(GPIO0, mode=IN)   (1) Pin(GPIO0, mode=IN, pull=PULL_UP)   (1) Pin(GPIO0, mode=IN)   
 1   (0) Pin(GPIO0, mode=IN, pull=PULL_DOWN)   (0) Pin(GPIO0, mode=IN)   (1) Pin(GPIO0, mode=IN, pull=PULL_UP)   (1) Pin(GPIO0, mode=IN)   
 2   (0) Pin(GPIO0, mode=IN, pull=PULL_DOWN)   (0) Pin(GPIO0, mode=IN)   (1) Pin(GPIO0, mode=IN, pull=PULL_UP)   (1) Pin(GPIO0, mode=IN)   
 3   (0) Pin(GPIO0, mode=IN, pull=PULL_DOWN)   (0) Pin(GPIO0, mode=IN)   (1) Pin(GPIO0, mode=IN, pull=PULL_UP)   (1) Pin(GPIO0, mode=IN)   
 4   (0) Pin(GPIO0, mode=IN, pull=PULL_DOWN)   (0) Pin(GPIO0, mode=IN)   (1) Pin(GPIO0, mode=IN, pull=PULL_UP)   (1) Pin(GPIO0, mode=IN)   

Which shows in the first 5 lines that as soon as a latchup(high) occurs, it stays there.
The second 5 lines do a PAD_RESET after each iteration.

[ayjaym]

Ok, well I have spent many hours now on this. This is what I know

1. The latchup issue is there both for no pullup/pulldown and for a pulldown
2. On cold power up, the 2350 GPIO ports all initialise to disabled and high impedance (but see below), and the 2040 GPIO ports appear to initialise with the 60K pulldown enabled.
3. You can reset 2350 GPIO ports to their initial power on state by using mem32 to access the GPIO registers. It's slightly non-trivial in that you seem to need to reconfigure the port to input mode, then set ISO and disable IE at which point it appears to be possibly to dynamically reconfigure them to any mode.
4. An ADC port can perform ADC reads without being configured from a cold start but will have a pulldown by default on the 2040 and not on the 2350.

Ok, so now the weird thing. With my touchscreen project the 2350 ADC will always report slightly high values (enough to screw up the tracking logic) for three or four X axis buttons (there are 16 in total) and this does not occur with the 2040.

Measuring the input voltage to the ADC at the anomaly point I see 1.25,1.40,1.52.1.69 on the 2040 and 1.25,1.5,1.63,1.79 on the 2350. Before and after this point the voltages converge back to the same values progressively.

Now at the point the code has for the 2040, the X+ pin set to logic 1, the X- pin to logic 0 and then Y+ is the ADC input and Y- is set to an input with no pullup i.e completely high impedance.

Because of errata 9 we can't do this on the 2350 so instead I reset Y- and X+ so that they should both be high impedance and then - theoretically, from an electrical circuit point of view, we should be in exactly the same configuration as the 2040.

BUT. Where is my tracking anomaly coming from? since the project just lets me plug in either board through ribbon cables, so we have an identical environment. The only thing I can think of is that the anomaly occurs around the logic 0 to 1 transition. If my supposedly 'high impedance' Y- pin is not in fact high impedance for specific voltage inputs, then it could source current and thus contribute an error but only for a specific input voltage range. You would need about 500uA across the approx 500 ohm resistance of the touch screen at that point to raise voltages by 0.1V.

This would be weird but we already know that E9 has completely screwed up the GPIO behaviour anyway. I will try and see if I can reproduce this with a pot connected to GPIOs which have been configured and then reset with my code on the 2350 to see if in fact they are a high impedance across all analogue input voltages. Otherwise I simply can't see a mechanism for the anomaly I'm seeing, since clearly the ADC itself is accurate, but the input voltage is too high for a limited range of values from the touchscreen. There are no other components connected to its four pins at all, so no other source I can think of for anomalous inputs.

[peterhinch]

I reset Y- and X+ so that they should both be high impedance

Is it possible that input pins are not high impedance, but in fact offer an impedance which is a function of applied voltage?

I think some actual measurements are called for. It would also be interesting to know what is the output impedance of a latched-up output. And how does a latched-up output behave if you briefly pull it low with an applied low value resistor.

[robert-hh]

When looking the state of RP2040 GPIO pins for PR #13509, it seemed to me that After reset the GPIO pins are in a kind of constant current sink mode of about 60µA for voltages above ~2V. At 3.3V that looks indeed like 55k. Below 2V it has more of a resistor characteristic.
PR #13509 sets the ADC to high impedance, if GPIO numbers like 26 are used, and does not change the input characteristic of channel numbers 0-3 are used.

[ayjaym]

Yes they are. I was misled by only cycling power to.the board but for some reason if you don't also do a machine.reset() you don't get consistent behaviour.
There are ADC anomalies and I have a simple test case but am not home at present. Will post details later

[ayjaym]

Long story short, I've posted in another thread but calling the ADC constructor after resetting the pin to be isolated and disabled for digital input via the GPIO register will cause the ADC input to actually emit a positive pulse of approx 2us and it can source at least 60uA of current when it does this. To see the issue, connect a low impedance pot (I used 5K) across 3.3V and ground and connect pin GPIO27 via a 1M resistor. Then read the ADC with

from machine import Pin, ADC,mem32
import time
import sys

def ResetPin(pin):
    GPIOBASE = 0x40038000
    if pin < 0 or pin > 28:
        raise ValueError ("Pin out of range")
    a = Pin(pin, mode=Pin.IN, pull=None) #otherwise output-configured pins don't reset properly
    addr = GPIOBASE + 4 + (pin * 4)    
    a = mem32[addr]
    a = a & ~0x40  | 0x100 # reset IE and set ISO
    mem32[addr] = a
    
def read1(adcdev):
    ad = ADC(adcdev)
    return ad.read_u16()

#a = Pin(27,mode=Pin.IN, pull=None) # 2040
ResetPin(27) # 2350, to get pin into high impedance state,machin
    
i = 0
while True:
    a=read1(27)
    i = i + 1
    if i % 10000 == 0:
        print(a, time.ticks_ms())

You will see that the ADC suddenly jumps from around 27000 to 41000 as the pot is turned and a good DVM across the resistor will show a sudden increase in voltage to over 1V - in fact there are brief pulses to Vdd if you look on the scope.

The 2040 doesn't have this problem and tracks smoothly with the input at 10s of megs at all times.

Now if you stop calling the constructor in a loop the anomalous behaviour goes away, but you can't solve the touchscreen issue with that because if you reset the pin after calling ADC and getting a reference, a subsequent call to read_u16() returns spurious values. You have to reconfigure with ADC but this means that because the pins have to be reconfigured to read X and separately to read Y, you have to call ADC in a loop and then for particular input voltages, you inject spurious signals into your circuit.

Note: even with a 10K resistor you still see the anomaly for certain input voltages, which were indeed around the logic 0->1 transition point, so I suspect the latchup mechanism is manifesting itself in a different way herel.

[ayjaym]

EDIT: Modified ResetPin to reset IE and set OD. This removes the need to transiently set the pin to an input and (hopefully) avoids the potential for a spike on the GPIO out while setting the pin to be high impedance.

Right, so miraculously I do have the touch screen working now as far as I can see. I did two things. Firstly I ensured that I only called the ADC constructor once when switching the pin configuration so that each ADC read could then just directly call read_16 on the ADC channel. I then do 20 reads and average out the values, but now I am not calling the constructor on each read, only when I switch configurations.

However this didn't fix the issue. What did fix it was to also stop setting ISO in my 'ResetPin' function.
For reasons I don't remotely profess to understand, this seems to have stopped the ADC overvalues.
I'll do some more testing but at present I may have things working. I can confirm that the code below does still correctly transition the pin to a high impedance state which does not latch, I have confirmed this using a 470K resistor from Vdd to the pin and then connecting that to ground from the pin and the pin will track properly and not latch up.
So a 'reset' pin can't do digital I/O but it can still do analogue I/O if it's an ADC channel of course.
And the WS2812 issues seem to be resolved with the added bypass caps, which the 2040 didn't need.
I avoid latchup by reversing the touch logic to start with a pullup, then I can detect a transition to logic 0 and switch to analogue read mode at this stage.

def ResetPin(pin):
    GPIOBASE = 0x40038000
    if pin < 0 or pin > 28:
        raise ValueError ("Pin out of range")
    addr = GPIOBASE + 4 + (pin * 4)    
    a = mem32[addr]
    a = a & ~0x40  | 0x80  reset IE and set OD
    mem32[addr] = a