PICO, rshell unwanted drop-outs to REPL

[davefes]

I have a PICO mounted on small piece of PCB, all ground pins are soldered to the PCB. I get many unwanted drop-outs to REPL when developing the code. I am using rshell.

I have tried init all GPIO to output and use 10K pull-ups on input pins. But if I touch any GPIO on the board with a paper clip I can easily provoke a drop-out to REPL.

Should the "ground plane" I have the PICO mounted on be connected back to a better ground on the computer? Static matt?

I never saw this problem with the ESP32 dev boards or bare modules. The PICO seems a lot more sensitive to the environment (EMI)?

[davefes]

Putting a 1nF disc cap to ground on pin16 (the only input pin) reduces the number of fails BUT I need a small delay before:

breakout = Pin(16, Pin.IN, Pin.PULL_UP)
sleep(0.01)  # maybe could be shorter
if not breakout():  # Pull down for REPL
    exit()

or it does exit().

[davefes]

This seems to help as well. pin16 couldn't be further away from the RP2040.

Hopefully, there is a better solution to this problem!

[davefes]

On further testing with just a blinking LED and touching pin16 intermittently, while connected to the PC USB port and no rshell running, I can tell the blink sequence is disrupted.

When the PICO is connected to a "real" 5V source the problem goes away. There is something going-on when the PICO is connected to a Linux computer USB port ... with no terminal program running.

[davefes]

Thought I'd try another laptop and blow-me-down ... a old netbook running Ubuntu 18.04LTS no problem. The newer laptop running Ubuntu 20.04LTS with modemmanager (usb-modeswitch) removed seems to be the culprit.

Any clues appreciated.

[davefes]

Followed-up several suggestions from Google but no progress. There appears to be some difference how the PICO interfaces to the USB port versus the ESP32.

[robert-hh]

From your previous comments I am not sure whether you removed the modem manager from your system. The modem manager looks for /dev/ttyACM? ports. That may explain the difference between the PICO and the some ESP32 versions, which register as /dev/ttyUSB?. As long as I had the modem manager active, it caused some unexpected events when working with a PyBoard (at /dev/ttyACM?).

[davefes]

On the non-working 20.04LTS
dave@davef:~$ ModemManager Command 'ModemManager' not found, but can be installed with: sudo apt install modemmanager

[peterhinch]

At risk of stating the obvious, are you sure there are no shorts between traces and pads on the rear of the Pico and the PCB?

I would repeat your tests with a bare Pico to determine whether you have a Linux issue or a hardware one. FWIW I have used various Picos on several Linux PC's without problems, including some mounted on PCB's of my own design. In my experience they are rock-solid reliable.

[davefes]

I read your comment on the other thread. There is a possibility I might be heading-off on a tangent, but with
the following program:

from time import sleep
from machine import Pin

led = Pin('LED', Pin.OUT)
led.off()

while True:
    led.off()
    print ('going to sleep')
    sleep(0.5)
    print ('waking-up')
    led.on()
    sleep(0.5)

if I touch the run pin with a short piece of wire it crashes ...I have even placed 3 disc caps (104, 102 and 10pF) from run to ground. If I touch it with a 3u3H RFC no problem. It seems to me that RF (WiFi) might be upsetting things. Even touching pin16 with the piece of wire, which is currently set as an output will reset the PICO.

I realise that one will not be doing this test in real-life but it seems to me that there is some connection between external interference, it's affect on the PICO and the different USB implementations.

[davefes]

A 100nF disc cap on pin16 stops the crashing, when touching that pin. The `run' pin is still "sensitive". I really need SMD caps as a broad-band bypass to be really effective.

Maybe, the RF-side is too ingrained.

[davefes]

To clarify as I started to use the term "crash". I mean that the USB interface to rshell stops working (20.04LTS), the PICO continues blinking the LED.

[GitHubsSilverBullet]

if I touch the run pin with a short piece of wire it crashes ...I have even placed 3 disc caps (104, 102 and 10pF) from run to ground.

Well, first of all it does not crash. It does a perfectly fine RESET.
With a quite high pull-up, it take almost no charge (only a few pico-Coulomb) to throw the RUN pin out of its delicate balance.
So a higher capacitor (not in the low pF but at least in the high nF range) in combination with an external pull-up resistor (this one only a very few kΩ as there's almost no current flow) will get rid of all your problems.
Static charge/discharge is a problem almost everywhere. So you need to make sure that even if you discharge your bodies charge into a pin, it shouldn't trigger (cross the threshold) of the Schmitt-Trigger.
With regards to the USB connection, take a look at dmesg. It'll most certainly show a disconnect. And the reconnect (if there's one) will likely use a different terminal-device (due to the short cycle)

[davefes]

@GitHubsSilverBullet ... had to sleep-on this one. Thank you for persisting in trying to describe a likely cause of the problems I have been seeing. This morning I decided to "change the environment" by taking the laptop and PICO away from the house.

I can not provoke the RESET or crashes on the USB port. Back into the house and the "problem" returns.

I am off-grid and my work area is about 3 meters away from a 3KW pure sinewave inverter. I have ESP32 modules in various control systems about 1 meter away and I have not seen issues like this. Maybe, I need to look closer!

I am down to a 1K from 3V3 to the run pin, I have read comments about connecting run directly to 3V3. pin16 was the only other pin which seemed sensitive to EMI.

As far as the USB connection ... rshell displays disconnect messages.

Thanks again.

[davefes]

Final hardware implementation to reduce the effect of local EMI on my cause of PICO resets. The caps are 100nF disc and the resistor is 1K. pin16 seems to be the only sensitive GPIO so using it as a "breakout" pin was unfortunate. Be aware the the run pin is still very sensitive and if you attach anything to this pin you could be in for some further trouble-shooting.

[mdbingers]

@davefes - I am experiencing similar issues with Pin16. I had it as an input that closed to ground (car chassis) when the vehicle was put in reverse. Whenever it went to ground the Pico would reset. A diode did not help. I moved the input to another pin and the problem went away. I haven't tested whether it's just Pin16 or possibly other UART-TX pins yet. I was glad (well, not really) to see that someone else had a similar issue.

EDIT - I was lucky enough to be able to reproduce the issue and test the other pins. Pin16 is definitely more sensitive than the others. Hope this helps someone else as it cost me weeks of time.