Did something in your recent changes/update make a major change in the way that USB communicates or that the code is compiled?

[QKillerQ]

Hi!

So, my project that i have been working on that uses your 1.3.1 release still works perfectly fine. I can edit it and compile it just fine.

I wanted to migrate those changes over to your current, 1.4.1 build. However, no matter how little of changes i make, if any, i can't seem to get it to compile right. The board will flash the firmware, but won't ever show up as a device, no OSD, no trigger response, nothing.

If i flash your binary .u2f file that you link to, that at least flashes and reboots then the OSD shows up (navigation buttons, etc don't work, but that's expected since i haven't changed anything in the global file yet.

however, if i download the code, and open it in VS and compile it (no changes made at all), it will compile without error, but then, when, when i flash it, it goes back to the unresponsive state.

I am using the XIAO 2040 board.

just hoping you could help shed some light on that so i can continue to update to your latest release as the base.

Thanks in advance!!

[ravinrabbid]

Hmm, lots of changes between those two versions, mainly refactoring ... so, many chances for me to mess something up :)

Most likely culprits are:

• 8aa8b12 The change to pico-sdk 2.2.0: Make sure the sdk is up-to-date if you provide it yourself, delete the whole build folder to force a re-download otherwise (deleting the build folder might be a good idea either way)
• GlobalConfiguration.h has been refactored, there might be some settings that are re-ordered, try to use the file from the repo and re-apply your changes again. Also completely erase the flash just to be sure.
• 9f3a704 The switch to C++20, should not be an issue if it compiles fine, but maybe make sure your toolchain is up-to-date.
• ce1416f The RP2040 zero board is the new default, you might need to change the PICO_BOARD back to the XIAO ... however this should not really be an issue to may knowledge.

Otherwise I don't see anything obvious, are there any hints in the compile log? Can you try to checkout the repo to a new, clean folder ... just to make sure there is no residue from any previous builds?

[QKillerQ]

@ravinrabbid,

Thank you sop much for the quick response. I have tried everything you mentioned countless times over the past few weeks, with no luck. Here is a link to my files that may help you: https://drive.google.com/drive/folders/1SRVYGN1tOJdW92INAHCvDz-r4FKHs6CE?usp=sharing

I don't want you to feel obligated or have to spend a lot of time looking at my files, I was just hoping that a quick glance my show something immediate that catches your eye and solved the problem.

Here's the info on what I am sharing in that link: Issue:

Your latest, pre-compiled binary works perfectly on my hardware, but when I compile from source with these changes, it doesn't work (black screen, no USB enumeration, nothing responds).

My Hardware:

Seeed XIAO RP2040
Internal ADC for drum sensors (GP26-29)
MCP23017 GPIO expander at I2C address 0x27 (for buttons/display via I2C)
OLED display at 0x3C (shares I2C bus)
I2C on GP6/GP7 (i2c1)
WS2812 LED on GP12, enable on GP11

Changes Made to Your Latest Code:

CMakeLists.txt:

Line 9: Changed board to seeed_xiao_rp2040 (was waveshare_rp2040_zero)
Line 33: Changed CMAKE_CXX_STANDARD to 17 (was 20)

include/GlobalConfiguration.h:

I2C pins: 6,7 (was 14,15)
Thresholds: 55,70,55,70 (was 10,5,10,5)
ADC channels: 1,0,2,3 (was 3,2,0,1)
ADC type: InternalAdc with 8 samples (was ExternalAdc via SPI)
MCP23017 address: 0x27 (was 0x20)
LED pins: 11,12 (was 25,16)

src/peripherals/Drum.cpp:

Line 38: Changed std::ranges::transform to std::transform (C++17 compatibility)
Line 87: Changed std::ranges::max_element to std::max_element (C++17 compatibility)

libs/mcp3204/src/Mcp3204Dma.cpp:

Line 131: Changed std::ranges::fill to std::fill (C++17 compatibility)

Result: Compiles without errors, flashes successfully, but firmware doesn't work (no LED, no screen, no USB).

I removed the build folder to save space....

Thank you so much

[ravinrabbid]

Strange, I compiled and flashed your files as-is and I seems to work just fine (no Display/Buttons because of the different config, but the USB device enumerates and I can trigger the the inputs by shorting the ADC pins.

So the issue is most likely triggered by some difference in the build environment. Maybe some VS Code plugin setting/cache, so compiling directly from the command line could be worth a try. Otherwise using git bisect to find the problematic commit could bring us closer to the issue.