Compiling binary fails with additional libraries

[Jediknite1101]

Currently building an arcade style controller for a rhythm game, Sound Voltex: Exceed Gear. Using the Joystick and PicoEncoder library I've got all the base functionality coded and tested. I'm starting to expand it's capabilities and offload these additions to core1. Whenever I include another library such as Adafruit_SSD1306.h or Adafruit_NeoPixel.h and call their respective constructors I get same compile/upload error.

Resetting COM14 Converting to uf2, output size: 147456, start address: 0x2000 Scanning for RP2040 devices No drive to deploy. Failed uploading: uploading error: exit status 1

I have separate sketches using each of the libraries separately, so I know they work with board profile and I've started integrating the code line-by-line to try to determine the fault and the binary fails to upload/compile despite Output messaging. I can comment out highlighted line in the screenshot and the code compiles perfectly. Does anyone have any idea's as what maybe going on? or something that I might have missed?

[earlephilhower]

The message below:

Resetting COM14 Converting to uf2, output size: 147456, start address: 0x2000 Scanning for RP2040 devices No drive to deploy. Failed uploading: uploading error: exit status 1

Is an upload one, and not related to the application you're compiling. It means that Windows wasn't able to talk to the USB serial port and hence couldn't get into upload mode on the Pico. Either the Pico itself has crashed or has IRQs disabled so that USB comms are dead, or Windows doesn't know about the port (missing INF, see Zadig in the docs).

The important thing is that the code you are compiling and trying to upload has no effect on the upload. Only what was on the Pico when you tried to reset it (i.e. the prior app has crashed, not this one).

Since you say it was working before, then most likely the Pico has crashed. You could hook up a PicoProbe to verify this.

If the Adafruit_Neopixel constructor tries to access any other object (i.e. SPI, Serial1/2, I2C, etc.) , that's not legal since there is no guarantee on the ordering of global object constructors. Like you said, you could try moving the creation to setup() with something like

...
Adafruit_NeoPixel *center;
...
void setup() {
    center = new Adafruit_NeoPixel(options...);
    ...
}

[Jediknite1101]

The idea of the the Pico crashing is interesting... Though I has tried moving the sketch over to different PC. There I tried, "Sketch > Export Compiled Binary" and then just copying the *.uf2 file to the pico. It does appear flash the board but it seems non-responsive (btn LEDs, serial prints, nothing).

I'll try moving the creation to the setup().... and I'll look in to getting a probe. I think I saw some videos online on using a second pico to do so.

Thanks for your help. Maybe I should step back, call this version done and actually play the game this headache was all for.

[earlephilhower]

Isn't half the fun of that kind of thing continually tinkering with the guts to make it work "better?" 😆

In any case, another Pico and some form of wire and connector are all you need for PicoProbe. I believe R.Pi sells a kit pre-flashed and wired in a nice box, but myself have just been using my 2nd purchased Pico + JST connectors for all my debug needs for a couple years now...

[Jediknite1101]

So I finally got around to tinkering some more and I think I've narrowed down the issue. How to fix it is so far beyond me. So I'll try just looking for an alternative. My issue seems to lie somewhere within the PicoEncoder.h library.

I can define a global encoder object, but just as soon as I init the [encoderName].begin() function in setup, it just not play well with multi-core or Adafuit_NeoPixel libraries. And as a result the IDE makes it appear that complies fine but once that UF2 gets loaded windows can't find the board's COM port and the IDE throws the error that it can't upload.

Essentially I started a new sketch and started adding one library defining it's object one by one and ended with PicoEncoder. If I don't use any other library and limit the sketch to Joystick and PicoEncoder, I get a working binary.

So I'm looking for another library or I'm going to learn awful lot about rotary encoders.

[Jediknite1101]

Short answer, try using NeoPixel_Connect. In the object definition you specify which PIO.

So I took my query to thePicoEncodergit repo. So apparently the issue is a conflict over both libraries (NeoPixel or PicoEncoder) trying to claim PIO0. It is a bit over my head but the developer did offer a work around. Still don't know if it will conflict with multi-core, but this was his interim solution.

You could start by checking the return value from the encoder being method. If that's negative, then calling update afterwards on an Encoder that wasn't properly initialized will block indefinitely with interrupts disabled, which would be consistent with what you are seeing. I can add a protection in the code to avoid this. It would still not work, but at least it wouldn't hang forever.
In theory, the PicoEncoder library needs a full PIO, but it should be able to handle 4 encoders out of that PIO, so you should still have one full PIO available for other code.