RP2350 Rev A Deadlock

[spit4520]

Hi Everyone,

I have tried making some tweaks to force the Pulldowns to be disabled on all of the GPIO pins for the Pico 2, but to no avail. I haven't been able to read any data in from my Pico 2, the system will dead lock with the following:

./sigrok-cli-NIGHTLY-x86_64-debug.AppImage -d raspberrypi-pico:conn=/dev/ttyACM0 -C D2,D3,D4 --samples 100 -c samplerate=50000 -O ascii:width=80:charset='_"\/' sr: serial-libsp: Error setting serial port parameters (110): Connection timed out. sr: srpico: 1st serial open fail No devices found.

When I run the same modified code on the original Pico, I am able to successfully take a trace:

/sigrok-cli-NIGHTLY-x86_64-debug.AppImage -d raspberrypi-pico:conn=/dev/ttyACM0 -C D2,D3,D4 --samples 100 -c samplerate=50000 -O ascii:width=80:charset='_"\/' sr: srpico: Drain reads sr: srpico: Drain reads done libsigrok 0.6.0-git-f06f788 Acquisition with 3/24 channels at 50 kHz D2:________________________________________________________________________________ D3:"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" D4:________________________________________________________________________________ T:^ 0 D2:____________________ D3:"""""""""""""""""""" D4:____________________

I don't really know how else to patch this out, perhaps there are other underlying issues with the new Pico 2 chip?

[TimoNotThy]

How did you get the pico 2 to connect? I've tried on fedora but it wouldnt work for me. Did you install any seperate drivers?

[pico-coder]

I haven't bothered to buy a PICO 2 because the changes weren't all that compelling (still 12Mbps USB). and having latched up GPIOs doesn't help the case either. But a few things that come to mind:

1. Make sure the device shows up via lsusb when you plug it in.
2. Sometimes putty or terraterm etc. do a better job creating a serial connection. You can send an "i" to the device and see if it responds.
3. When you rebuilt the uf2, did you specify the build for the 2350? (I could be wrong, and haven't bothered to look, but it's reasonable to assume that some kind of device specific code of the rp2040 doesn't match the 2350.?)

[pico-coder]

Also, gusmanb (https://github.com/gusmanb/logicanalyzer ) under the "born dead" section seems to imply that the pull up situation makes a PICO 2 useless as a logic analyzer. I can't confirm or deny the analysis, but I'd at least recommended reading the Errata from raspberry PI and seeing if you agree before trying further.

[pico-coder]

See also https://forums.raspberrypi.com/viewtopic.php?t=375954 from Dr. Gusman

[spit4520]

Hi Pico-Coder/Sigrok-Pico, I built the firmware for the PICO2, the interest in using it would be to port and embed the firmware in a signed encrypted flash embedded in our product to take PCAP files in the field or raw trace files to diagnose issues. The 2354A is a co-processor to our main application, and in the debug mode it will act as a debug probe. I can see a lot of use for an application like this in early IoT applications until the first generation or two have worked out a lot of the kinks. I checked Errata 9 and we have A2 revision parts, I may have misread the documentation but I thought we could get around the issue by disabling the internal pull ups and pull downs? Grateful for any feedback, Scott

…

On Tue, Dec 3, 2024 at 12:53 pico-coder ***@***.***> wrote: See also https://forums.raspberrypi.com/viewtopic.php?t=375954 from Dr. Gusman — Reply to this email directly, view it on GitHub <#55 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AESOJ7PWLPPK7KE5PKTQ4CL2DXVYJAVCNFSM6AAAAABS42OHCWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMJVGIZDSMZUGQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[pico-coder]

Again, I can't confirm or deny the Errata issue, but assuming that isn't a problem, the next step is to ensure the device does show on an "lsusb" and that you can establish a serial connection to it -either with putty/terraterm etc or just a sigrok-cli scan.

[spit4520]

Hi @pico-coder

The 2350 enumerates over lsusb, though it is extremely slow I might add:

Bus 001 Device 059: ID 2e8a:0009 Raspberry Pi Pico

Here is the dmesg --follow trace for the Pico:

`[96504.313760] usb 1-12: Product: Pico
[96504.313765] usb 1-12: Manufacturer: Raspberry Pi
[96504.313769] usb 1-12: SerialNumber: CCC779399698F641
[96509.538003] cdc_acm 1-12:1.0: ttyACM0: USB ACM device
[96533.236417] usb 1-12: USB disconnect, device number 57
[96536.137073] usb 1-12: new full-speed USB device number 58 using xhci_hcd
[96536.288166] usb 1-12: New USB device found, idVendor=2e8a, idProduct=0009, bcdDevice= 1.00
[96536.288183] usb 1-12: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[96536.288190] usb 1-12: Product: Pico
[96536.288194] usb 1-12: Manufacturer: Raspberry Pi
[96536.288199] usb 1-12: SerialNumber: CCC779399698F641
[96541.791348] cdc_acm 1-12:1.0: ttyACM0: USB ACM device
[96630.500873] usb 1-12: USB disconnect, device number 58
[96630.501427] cdc_acm 1-12:1.1: acm_start_wb - usb_submit_urb(write bulk) failed: -19
[96630.501534] cdc_acm 1-12:1.1: acm_start_wb - usb_submit_urb(write bulk) failed: -19
[96630.501564] cdc_acm 1-12:1.1: acm_start_wb - usb_submit_urb(write bulk) failed: -19
[96630.501579] cdc_acm 1-12:1.1: acm_start_wb - usb_submit_urb(write bulk) failed: -19
[96630.501591] cdc_acm 1-12:1.1: acm_start_wb - usb_submit_urb(write bulk) failed: -19
[96630.501603] cdc_acm 1-12:1.1: acm_start_wb - usb_submit_urb(write bulk) failed: -19
[96630.501614] cdc_acm 1-12:1.1: acm_start_wb - usb_submit_urb(write bulk) failed: -19

[96664.502836] usb 1-12: new full-speed USB device number 59 using xhci_hcd
[96664.653463] usb 1-12: New USB device found, idVendor=2e8a, idProduct=0009, bcdDevice= 1.00
[96664.653481] usb 1-12: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[96664.653487] usb 1-12: Product: Pico
[96664.653492] usb 1-12: Manufacturer: Raspberry Pi
[96664.653497] usb 1-12: SerialNumber: CCC779399698F641

[96669.780614] cdc_acm 1-12:1.0: ttyACM0: USB ACM device

[96787.184362] usb 1-12: USB disconnect, device number 59
` (CDC-ACM took about 5 seconds to register)

minicom really doesn't like trying to connect directly to the 2350, it hung several times and I noticed failed blk operations when trying to write to the device.

When I scan for devices with sigrok-cli, it can see the pico2:

/dev/ttyACM0 Pico - CCC779399698F641

The rp2040 works just fine, but here are some benchmarks for comparison

Bus 001 Device 061: ID 2e8a:000a Raspberry Pi Pico (took under a second to index)

[97547.252215] usb 1-12: USB disconnect, device number 61 [97548.789218] usb 1-12: new full-speed USB device number 62 using xhci_hcd [97548.940400] usb 1-12: New USB device found, idVendor=2e8a, idProduct=000a, bcdDevice= 1.00 [97548.940417] usb 1-12: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [97548.940425] usb 1-12: Product: Pico [97548.940430] usb 1-12: Manufacturer: Raspberry Pi [97548.940434] usb 1-12: SerialNumber: E6612483CB0D632B [97548.947623] cdc_acm 1-12:1.0: ttyACM0: USB ACM device (CDC ACM class registered in under 70 milliseconds)

/dev/ttyACM0 Pico - E6612483CB0D632B sigrok can find the device just fine

my educated guess is that something is wrong with the USB clock or a peripheral clock. There is a lot of very specific code in the repo targeting the individual hardware registers and I am guessing that the abstractions provided by the Pico SDK need to be ported over to have 1:1 parity. The Pico 2 is about ~10% - 16% different to the Pico 1, but these hardware blocks should be unaffected in theory??

Let me know how I can help, really excited to get this working

[pico-coder]

I don't actually have a PICO 2 so can't test anything and probably won't be much help. Being that USB connects at all would seem to imply to me that those clocks are correct, but maybe the core or other clocks are messed up. I did a quick scan through the code and it looks like I usually used register names provided by the SDK. You could perhaps try to connect the serial debug on D0/D1 to see if anything comes out there. You might also check gusmanb's site to see if he has any updates for the PICO 2, though I'm not sure if he released anything there or not.

[c1570]

The code of sigrok-pico is not suitable for the RP2350 as many registers have changed offsets compared to the RP2040.

See https://github.com/c1570/sigrok-rp2350b for a variant suitable for the RP2350B (and for the RP2350A, with minor tweaks). It's mostly untested yet though.

[ohault]

About Pico 2 and Pico 2 W, what kind of support are we going to have ?

[c1570]

@ohault You can try the Pico 2 build from https://github.com/c1570/sigrok-rp2350/tree/rp2350/pico_sdk_sigrok/build .
Personally I don't have immediate plans for the Pico 2 as I'm more interested in the RP2350B boards (I might try to extend this to 48 digital pins) but the Pico 2 is pretty similar.

[pico-coder]

@c1570 thank you very much for finding those deltas. Your changes look pretty straightforward. Was there any particular motivation to changing the base sample rate from 5k to 1M other than just a personal preference ?

[c1570]

@pico-coder That was mostly because for debugging I just connected using Minicom, and after D101 C it would hang for a rather long time (since filling up one buffer at 5000 bits/sec takes quite a while). A better solution (that would also reduce latency) would probably be reducing buffer sizes at low sample rates.

BTW I'll try setting up a test case for sigrok-pico using https://github.com/c1570/rp2040js/ which should make refactoring and optimizations a bit easier.

[pico-coder]

I just pushed a major code release, and in the release directory are new uf2s with "pico2" in their name that support RP2350.
Please try those out and let me know how it goes, but RP2350/PICO should now be "supported".
As for wifi, I don't have any particular plans. See #21. Wifi will be fundamentally slower than USB and I haven't yet found a good leverage point of a wireless libsigrok device to work from.

[pico-coder]

@c1570 , I forgot that you had a separate cloned repo with some fixes. Due to the pervasiveness of changes in the rewrite your changes don't carry over directly. I did try to make sure that I didn't use an RP2040 specific field, and then did separate builds for RP2040 and RP2350. Please let me know if there is anything I missed from your repo that I should pull in.