Issue in detection of RPI pico as device

[chaitanya-smartrotamac]

I am a hobbyist and very much interested in your project. It was soo great with this Hardware+Software we can analyze most of the protocols and the main thing is it was soo economical. when I saw your repo I straight away downloaded uf2 and programmed my pic to test it.

Issue : When I connected my Pico with flashed uf2 opened the pulseview and can't find the pico detected. I am disappointed. I clicked multiple times.

• Why was this happening?

Then what happened :

I opened my realterm(serial software) opened the port and closed it again.

it told me the port was open.

so I disconnected pico and connected it again.

still, pico is undetected by the pulseview

Now I disconnected and connected again and opened my realterm and connected open and closed the port

Now when I tried in Pulseview I can find it

Every time I need to follow this process: 1) Connect pico to USB open realterm(or any serial interface SW like putty) 2) Open the port and close it. 3) Open the Pulseview then search for pico 4) Detected and working.

-- Why is this happening? is it by WIN10 issue or something with firmware? -- Can I log something to show more data on what's going on when not detected?

[pico-coder]

Agreed. There is something very strange with USB CDC device enumeration on windows that hits a lot of people, including me. Usually doing a reboot or a using a terminal program to initiate an initial connection or unplugging it or .... seems to work. And once it works once it usually seems to be reliable. Exactly what putty/terraterm do to open a port that sigrok/my driver don't do I'm not sure. It really is a "open port, send some bytes".

I'm a bit lost as to where to start though, as much of the device code is buried in the OS or part of the serial libraries or who knows where... My latest though is to add more debug code on the PICO to see if anything is ever reaching the device to see if perhaps there is something in the initial code sequence that throws off windows, but I'm not sure what that would show. Further, running at debug level 5 (-l 5 on the command line) might allow useful stuff to show up in the pulseview logs.

I'll keep this alive for a while as I'm sure others are seeing it, maybe a Windows 10 USB CDC device expert will stop by...maybe not...

And thank you very much for the detailed information in the issue submission.

[pico-coder]

got some testing in today. I was able to recreate the problem if I reboot my PC and run pulseview with a windows icon, for instance: "C:\Program Files (x86)\sigrok\PulseView\pulseview.exe" -d raspberrypi-pico:conn=COM7:serialcomm=115200/flow=0 -l 5 When I do that and check the pulseview log I see this: sr: hwdriver: Scan found 0 devices (raspberrypi-pico). sr: hwdriver: sr_config_list(): key 2147418112 (NULL) sdi 00000000 cg NULL -> [uint32 20000, 20001] sr: srgn: Opening COM7. sr: serial: Opening serial port 'COM7' (flags 1). serial-libsp: Error opening port (5): Access is denied.. sr: srgn: 1st serial open fail sr: hwdriver: Scan found 0 devices (raspberrypi-pico).

However, when I go an directly find the pulseview app and click on directly, i.e. C:\ProgramFiles(x86)\sigrok\PulseView\pulseview, then I'm able to find the device.

The access is denied error typically happens when another program has a device open. So I think what might be happening is that if the device configuration is specified to the command line that pulseview opens the com port once, and then it gets opened again when the driver is called and the driver fails to open it because it is already opened.

I also confirmed the same behavior that if you open and close the port with a serial program things work ok.

So, if you could confirm the same behavior that you can connect if the COM port is not on the command line that would be helpful. Also, if you can always run with verbosity level 5 (either via -l 5 on the command line or by the settings from the gui) and add some logs here that will help as well.

Also, one more note, please make sure you don't have any other serial port applications open when doing this. I'm guessing that you don't, but wanted to mention it. Thanks, Shawn

[pico-coder]

My apologies, I think the problem was just a copy error on my part. When you specify the serialcomm, you must specify dtr=1. If you don't then transmissions are not enabled and nothing gets sent. In the default code I wrote (api.c) dtr is set to 1, but in the example windows icon I forgot to include it. So if you do something like this it should work for the icon.

"C:\Program Files (x86)\sigrok\PulseView\pulseview.exe" -d raspberrypi-pico:conn=COM7:serialcomm=115200/dtr=1/rts=0/flow=0 -l 5

The reason that doing putty/terraterm etc makes it work is that once you set dtr it's setting remains persistent across opending and closing across the applications.

[chaitanya-smartrotamac]

My apologies, I think the problem was just a copy error on my part. When you specify the serialcomm, you must specify dtr=1. If you don't then transmissions are not enabled and nothing gets sent. In the default code I wrote (api.c) dtr is set to 1, but in the example windows icon I forgot to include it. So if you do something like this it should work for the icon.

"C:\Program Files (x86)\sigrok\PulseView\pulseview.exe" -d raspberrypi-pico:conn=COM7:serialcomm=115200/dtr=1/rts=0/flow=0 -l 5

The reason that doing putty/terraterm etc makes it work is that once you set dtr it's setting remains persistent across opending and closing across the applications.

Wow, That worked. I added to the shortcut with the respective port and bandwidth and it directly opened PICO. will you release this in next version?

I am looking at upgrading the 3.3v signals to 5v compatible so it can be useful to check most of the digital signals. can you suggest me best and easy methods?

I am checking|||| https://github.com/gusmanb/logicanalyzer @gusmanb Agustín Gimenez Bernad |||| work. But he works on his own software binary protocols ...which is the limitation.

I am thinking of developing a small python GUI for the signal generator to integrate your >https://github.com/pico-coder/sigrok-pico/blob/ccf0b32ab74817c4f981bbbb69dfea398ba77414/pico_pgen/pico_sdk_pgen.c If that works I have fully functional Signal generator Signal/Logic/Protocol analyzer

[AapoTahkola]

Looks like I am having the same issue on Linux. Have not figured out yet which params to pass to pulseview.

sudo chmod a+rwx /dev/ttyACM2
pulseview -d raspberrypi-pico:conn=/dev/ttyACM2:serialcomm=115200:dtr=1:rts=0:flow=0 -l 5

gives

sr: [00:00.458560] srgn: Opening /dev/ttyACM2.
sr: [00:00.458565] serial: Opening serial port '/dev/ttyACM2' (flags 1).
sr: [00:00.458572] srgn: 1st serial open fail
sr: [00:00.458575] hwdriver: Scan found 0 devices (raspberrypi-pico).

As as side note there were I think two errors in the build instructions. The path to cd is pico_sdk_sigrok and I think the build directory already exists. Secondly I think you meant to apply the patch with "patch -p1 --dry-run < patch_file.patch" and then replace the files from the pull request. Also I think libsigrokdecode might be worth compiling after the main library is done.

[pico-coder]

My linux pulseview builds are broken at the moment (long story) so I can't test that command line on linux, but using sigrok-cli the problem might be that your serial comm is using colons instead of slashes. For example this doesn't work: ~/github/sigrok-cli/sigrok-cli -l 2 -d raspberrypi-pico:conn=/dev/ttyACM0:serialcomm=115200:flow=0 --scan but this does: ~/github/sigrok-cli/sigrok-cli -l 2 -d raspberrypi-pico:conn=/dev/ttyACM0:serialcomm=115200/flow=0 --scan

[pico-coder]

BTW, with verbose logging this should show up in the logs and thus gives you the parameter list that made it to the driver, so you can see whether it is not getting passed due to the ":" vs "/". Note that even if the list does make it that far it still may not be parsed correctly by the serial libraries it is sent to... sr: srgn: At scan sr: srgn: Scan set serialcomm: 115200/dtr=1/rts=0/flow=0 sr: srgn: Scan set conn: COM7

[AapoTahkola]

serial_open is returning -6(SR_ERR_NA). Tried hard-coding serial->lib_funcs to hid serial which led to SR_ERR_ARG. I have no idea what I am doing here. No arg list that I can see.

[AapoTahkola]

I noticed that rpi pico is using tinyusb which is essentially software usb implementation. Not sure how reliable this implementation is these days but I have had problems with it in the past. I think I will go to the pico examples because I cannot seem to be able to even view the debug messages with a terminal emulator. I cannot find this "Scan set" string in any of the sigrok sources.

[pico-coder]

@AapoTahkola . Please make sure you've downloaded the right uf2 file for the PICO. https://github.com/pico-coder/sigrok-pico/blob/main/pico_sdk_sigrok/build/pico_sdk_sigrok.uf2

Once it is programmed do an "lsusb" to make sure the device shows up under linux.

Then you can open any terminal program you like and send it a single asterisk "*" which is a reset, and then send the letter "i" followed by enter. The i is an identify and should come back with a string with "SRPICO" in it. If that isn't happening then you have some issue with programming the device or maybe some issue with USB CDC on your system.

[AapoTahkola]

@pico-coder Yeah at least with the prebuilt firmware the commands do respond with picocom 115200 speed. What I find interesting is that if I select "Connect to device" with pulseview and raspberrypi-pico, serial port, 115200 speed it does not matter if I write "/dev/ttyACM0" as the device or "raw=/dev/ttyACM0", "conn=/dev/ttyACM0:serialcomm=115200/dtr=1/rts=0/flow=0" or anything I still get:

sr: srgn: 1st serial open fail
sr: srgn: ret -6

It looks a bit like it is not passing any params. I have not found where in libsigrok these params are being handled. "/sigrok-cli -l 5 -d raspberrypi-pico:conn=/dev/ttyACM0:serialcomm=115200/dtr=1/rts=0/flow=0 --scan" outputs:

srd: libsigrokdecode loglevel set to 5.
sr: [00:00.002878] hwdriver: sr_config_list(): key 2147418112 (NULL) sdi (nil) cg NULL -> [uint32 20000, 20001]
sr: [00:00.002884] srgn: Opening /dev/ttyACM0.
sr: [00:00.002886] serial: Opening serial port '/dev/ttyACM0' (flags 1).
sr: [00:00.002888] srgn: 1st serial open fail
sr: [00:00.002889] srgn: ret -6
sr: [00:00.002891] hwdriver: Scan found 0 devices (raspberrypi-pico).

It does respond to changes in serial device though.

[pico-coder]

I tried that sigrok-cli command on my raspberry pi model 3 and it works fine to find the device.

As for how the flows work: The conn and serialcomm parameters are passed to api.c :

/src/hardware/raspberrypi-pico/api.c Api.c calls the libsigrok serial wrapper code "serial_open" function at /src/serial.c Inside of the serial_open function in serial.c are a few SR_ERR_NA returns. SR_ERR_NA is defined as -6 in include/libsigrok/libsigrok.h Likely you could add some debug sr_err printouts to src/serial.c to see which if clause is failing. I've never had to mess with that function so no idea what is going on.. Good luck and let me know what you find.

[pico-coder]

Also, you should run a sigrok-cli scan to make sure you have the right port, here is what I get:

/sigrok-cli --list-serial Available serial/HID/BT/BLE ports: /dev/ttyAMA0 ttyAMA0 /dev/ttyS0 ttyS0 /dev/ttyACM0 Pico - E6605481DB9F6135

[pico-coder]

FYI, here is the logs I get from the serial open, so we at least have the same first two lines.

sr: [00:00.020533] srgn: Opening /dev/ttyACM0. sr: [00:00.020571] serial: Opening serial port '/dev/ttyACM0' (flags 1). sr: [00:00.023453] serial: Parsing parameters from "115200/dtr=1/rts=0/flow=0". sr: [00:00.023987] serial: Got params: rate 115200, frame 8/0/1, flow 0, rts 0, dtr 1. sr: [00:00.024069] serial: Setting serial parameters on port /dev/ttyACM0. sr: [00:00.025892] serial: DBG: serial_set_params() rate 115200, 8n1 sr: [00:00.026031] serial: Flushing serial port /dev/ttyACM0.

[AapoTahkola]

serial_open was failing because I did not have libserialport-dev installed when compiling libsigrok so "serial->lib_funcs" was null. However that still did not fix it. Now pulseview detects the /dev/ttyACM0 pico device but scan fails with:

sr: serial-libsp: Error opening port (25): Inappropriate ioctl for device.

Same with sigrok-cli. I'll look into in a bit more detail later. Kind of starting to get temptations playing with pico w wifi stuff.

[AapoTahkola]

Uninstalling libserialport-dev, installing git version of libserialport and recompiling libsigrok solved rest of my issues.

[pico-coder]

Thanks for the feedback. Eventually I need to try to get the linux installer to build so people can install directly, but won't get to that for a bit. Closing this since issues are resolved.