Strange uploading issue - choice of GPIO breaks uploading process

[w9ran]

I have a Pico program that works fine on a breadboard, but for some unknown reason fails to upload correctly to my prototype PC board. Different Picos, obviously, but the only difference is four GPIOs used to read a BCD input that were changed from 10-11-12-13 on the breadboard to 18-19-20-21 on the PCB . It's worked in the past but today when I upload the correct code to the PCB the IDE gives the following errors:
Resetting COM24
Converting to uf2, output size: 172544, start address: 0x2000
Flashing K: (RPI-RP2)
Wrote 172544 bytes to K:/NEW.UF2
Error opening serial port 'COM24'. (Port not found)

After one attempt the Pico is unavailable as a serial device, Windows give the "last USB device has malfunctioned" error and the only way I can bring it back is to start it with the BOOTSEL button held down and drag-drop a uf2 file on the mass storage device, then the Pico resumes normal operation.

The weird part is, I can then upload the code for the breadboard to the PC board hardware and it will work fine, except for the function that requires the BCD data since it's looking at the wrong four GPIOs. I've put both into DiffChecker and confirmed that the only difference is the GPIO assignment and pinmode configurations - 5 removals and 5 additions and the only difference in those lines are the pin numbers:
This works: int BandInput[] = {10, 11, 12, 13};
This blows it up: int BandInput[] = {18, 19, 20, 21}; (and the associated pinmode statements for each)

I can't see how the choice of GPIOs could cause the symptoms I'm seeing. I searched for the uf2 file and none is being created - only the elf - so I used elf2uf2 to make one and uploaded it using BOOTSEL but it still doesn't run. Both versions compile without error, the only indication of problem is when the IDE tries to upload the UF2 serially to the Pico (and I'll admit I'm not fully up to speed on the exact boot- boot2 sequence of operations).

So as a last resort I commented out the five lines in the PCB version and copied in the same ones from the breadboard, which are incorrect for this hardware, but after restoring the bootloader I successfully uploaded it and it works.

I'd really appreciate if anyone can explain how my choice of GPIOs manages to break the uploading process! Of course I may be missing something obvious - so any suggestions are appreciated.

Thanks,
Bob

[earlephilhower]

The serial port doorbell method requires the Pico code to be running properly and not crashed. That's probably what is happening here, the code is crashing somewhere with your other pinout (w/o full source it's hard to really say, if you can make a small 1-screen sketch that repros the problem it would be much better).

As a simple sanity test to ensure its not something physical on the PCB (i.e. 5V devices, noise on power when the pins are used w/real HW), can you run the PCB binary that always crashes on the breadboarded version while rewiring the pins on the breadboard to match the PCB? If that doesn't fail, I think it points to a PCB issue.

If you have a debug header, it would be very instructive to hook up a Picoprobe and dump the CPU states. You can get full stack traces/etc. to tell you exactly where things are panic() or crashing.

FWIW, the GPIO pins listed seem like they are safe to do regular GPIO from. But, if your sketch/libraries try to use HW interfaces like SPI or I2C then it's possible those PCB pins are not legal for the given HW.

[w9ran]

Thanks very much for your reply! I wrote simple test sketch only including Arduino.h but without any of the other libraries I'm using and it works as it should:
// sketch to test reading GPIO 18-21 into array

#include "Arduino.h"
int BandInput[] = {18, 19, 20, 21};
unsigned int band;

void setup() {
// put your setup code here, to run once:
pinMode(18, INPUT_PULLUP); // band encoding
pinMode(19, INPUT_PULLUP); // band encoding
pinMode(20, INPUT_PULLUP); // band encoding
pinMode(21, INPUT_PULLUP); // band encoding

Serial.begin(9600);
}

void loop() {
// put your main code here, to run repeatedly:
// Scan the band select inputs
band = 0;
for (byte x = 0; x < 4; x++)
{
byte value = digitalRead(BandInput[x]);
band = band + (value << x);
}
Serial.print ("Value is ");
Serial.println (band);
delay (500);
}

This rules out a problem with PCB (or the Pico, ha!) I think as you suggest, the problem must be a conflict with some pins that have been defined (somewhere?) to be SPI or I2C which are now in conflict with what I want to do.

I am using GPIO 16 and 17 for I2C0 in my setup:
Wire.setSDA(16);
Wire.setSCL(17);
Wire.begin();

Since 18-19-20-21 are able to be used for I2C and/or SPI - even though I am not using them - do I need to "unassign" them somewhere to free them up to be used as GPIO? I've looked at your Wire.h and it appears that all that's needed is setSDA and setSCL as I've done.. Is there any other way (than in my code) that these pins can be reconfigured?

I've included all the libraries I'm using in the test sketch and it doesn't fail, but of course no calls are being made to them. Two of them support I2C devices, such as the Adafruit_SSD1306,h oled display library which itself makes calls to Wire.h:

#include <Adafruit_GFX.h>
#include <SPI.h>
#include <Wire.h>

I'm not sure how - but clearly these calls would need to go to your Wire.h, not the ones associated with Arduino, Arduino Mbed, etc - right? I suspect if I incrementally add back the piece of code associated with them, eventually the problem will occur.

Any suggestions as to how I can identify the source of the conflict?

I'm not up to speed on using Picoprobe but it sounds like I'd better learn.
Thanks,
Bob

[earlephilhower]

That Wire pinout looks OK (setting illegal I/O pins is a common panic() causing code problem). What about the SPI pinout, since I see you're including that lib?

Unfortunately w/o code there's not much anyone but you can do. Add things back in one at a time, I suppose, to at least figure out which library is causing the issue.

Wiring up the debug header, assuming you're running a Pico RP2040 board, is trivial, as is flashing the PicoProbe FW to a second device. Only issue I've had is ensuring the proper orientation (fixed by soldering on keyed JST connectors). The readthedocs in the README.md or the Pico SDK documentation can help you get going. (Once you get SWD debugging running, you'll wonder how you lived without it, believe me!)

[w9ran]

Thanks for the suggestion - but as I tried to watch the Digikey Picoprobe video again my eyes glazed over about halfway through. If someone could simplify the use of this tool I'd be all over it. To be honest, the reason many of us are able to play with the Pico is because you (brilliantly, I might add) provided support in the Arduino IDE which, warts and all, is where us hobbyists who aren't professional embedded developers feel comfortable. In addition to the learning curve for VSCode, OCD, and all - I'm not sure the Picoprobe would help debug my application because I'm already using both PIOs and I read that it uses a PIO for the SWD interface.

And to be clear, the code snippet above which includes the SPI library is from the Adafruit SSD1306 library. I use I2C but not SPI, but I reckon the reason it's included is because she typically writes libraries that support multiple Adafruit products.

I've also used the Arduino Mbed core, and it uses a file called pins_arduino.h to describe the configuration of all pins that are used. Does your core have anything similar that I should be modifying? Or how would I tell your core that I want to use pins 18-21 for GPIO rather than I2C or SPI? Or if some library I'm using is doing that how could if determine which one is doing it? I realize the Picoprobe might do that - but it would sure be nice if it was easier to use.

I'll be happy to send you my entire code if you'd like to look at it. Thanks again for your help and time.
Bob

[w9ran]

Thanks again, Earle. Since I don't want and am not using SPI all I need to do if figure out how to eliminate the conflict. With a couple of simple changes I modified my code so it compiles and runs using the Arduino Mbed core, where I know how to define the IO pins, so that confirms the problem, and if I can do the same with your core, I'll be able to switch back. In the meantime I can at least continue with my development.

You convinced me of the value of Picoprobe! After a couple of fun-filled (!) hours of installing the toolchain, I am one issue away from having VSCode working (Unable to determine what CMake generator to use error) - then I can get on with SWD, GBD, et al. I found a good tutorial except for this problem which others have also had and which has not been addressed, so I'll check the docs you referenced.

I've been around embedded software long enough to realize what an amazing thing it is to be able to have a realtime in-circuit debugger for $4! (As in from back when PIC was made by General Instruments, which has been defunct since 1997!). But it's all about learning, so thanks again.
Bob

[w9ran]

Hi Earle,
I'm still stuck on this issue, but maybe I can frame the question specifically enough that you can offer a suggestion to fix it.
I only want to enable I2C0 on GPIO 16 and 17, which are the default pins. I DO NOT want any I2C1 or SPI on pins 18 and 19 or I2C0 on pins 20 and 21, which are also shown as the Pico default pins so I can use 18-19-20-21 as GPIO.

In my setup function I use the following to initiate I2C0 on 16-17 before Wire.begin();
Wire.setSDA(16);
Wire.setSCL(17);

My read of the docs is that this is all that's necessary but this does not work. When I go back to Arduino Mbed core and do the same thing to initiated only one I2C0 on 16 and 17 it works.

So my question is; Specifically, how do I "unspecify" the use of 18-21 for any other purposes using your core?

Again, I am not using any SPI and only one I2C and have confirmed that the problem is unique to your core. I know how do edit the pins_Arduino.h file to select the desired IO usage with the Arduino Mbed core - if there is something similar for your core that I am missing, please point it out to me, thanks.

Bob

[earlephilhower]

If you do not use a HW resource, it doesn't matter what the pinout is. The HW itself isn't activated, so plain GPIO use is always fine. I use GP0 and GP1 all the time even though they're UART0 on the RPi Pico board, for example.

So, I really don't think it's the pinouts. I only brought it up because you listed SPI.h as an included header above.

I think that without an MCVE (1-screen size app that demonstrates the problem) there's not much I can suggest at this point.

[w9ran]

Well I found the problem, and it was in the chair not in the computer ;-) I'd inadvertently been including some I2C configuration lines that the Mbed core tolerated, but yours did not - but which were unnecessary in any case. Please accept my appreciation for your patience and willingness to help, in addition to all the great software tools you have given us, it is much appreciated. I've learned some things in the process and only by trying to create an MCVE was I forced to see what I'd been overlooking before. Thank you.
Bob

[earlephilhower]

No worries, and thanks for following up!