foone OP , vor 2 Tagen

which would normally suggest that there's some issue with the hardware but I can push the BOOTSEL and and reconnect and get it back into programming mode just fine!

and I can flash circuitpython onto it and have that work just fine too

foone OP , vor 2 Tagen

so there's something wrong with my code, I guess. what is it? I have no way to know, because I have no errors and no debugging feedback

foone OP , vor 2 Tagen

ARGH my codebase has two copies of the known-working code and the code is identical but the CMakeFiles are different and one works and the other doesn't

foone OP , vor 2 Tagen

both compile just fine without errors, but one of them apparently results in a dead pico that can't enumerate

foone OP , vor 2 Tagen

I fixed it (god only knows how) but now the printer won't print.

A_C_McGregor , vor 2 Tagen

@foone That's just default printer behaviour. Try threatening to dismantle it with a hammer.

keithmann , vor 2 Tagen

@foone Fixed for certain values of "fixed" eh?

raptor85 , vor 2 Tagen

@foone best guess: the one that doesn't work is likely not stripping the elf header after compilation, elf only works if you have a loader for it, if you want a raw executable(like to load as firmware) you gotta trim it off and start the code from the address of the _start symbol.

Don't know for sure obviously but that's the most likely culprit always in situations like this.

pancomputans , vor 2 Tagen

@foone Always nice to have a reminder why DRY is actually useful.

ChuckMcManis , vor 2 Tagen

@foone Don't suppose you have the SWD access? If so using the BlackMagic Probe is pretty straight forward. If not it is definitely tough sledding.

Jhynjhiruu , vor 2 Tagen

@foone I like to connect two of the pins to act as UART and configure the SDK to do C stdio over that (there's a CMake function for it)

vurpo , vor 2 Tagen

@foone pi pico uses a fully software implementation of USB (not hardware), so if the software doesn't work then it literally isn't USB and won't enumerate