Add option for not enabling USB

[tvlad1234]

Hello! First of all, I would like to thank you for this awesome project, thanks to it the Pico is now my favourite ARM board 😃.

I am currently playing with @majbthrd 's pico-debug project, which uses the second core of the RP2040 as a CMSIS-DAP debugger for the main core. Using it implies that the main core can't touch the USB peripheral at all without breaking the debugger. I got it to work with Arduino sketches by commenting the __USBStart() function in main.

My idea is to have an option in the board config (perhaps under the USB Stack menu) to not enable the USB functionality in the sketch.

[tvlad1234]

I managed to add the option myself. Should I open a pull request?

[earlephilhower]

This sounds very neat. Are you going to try and integrate the debugging 2nd core stuff as well?

I think this could be an extension of the USB Stack menu, and while you're adding it the DISABLE_USB_SERIAL flag would be good, too, just for completeness.

FYI, the boards.txt file is generated from tools/makeboards.py so that's where your changes should be centered.

[tvlad1234]

For coding and debugging, I'm using VS Code with the Cortex Debug and Arduino extensions. I suppose I could try to integrate debugging with the Arduino IDE 2.0 beta, as it's based on VS Code (and Cortex Debug). However, I had to recompile OpenOCD, as the one included with this core didn't work at all on my machine (I'm on Windows).

Sure, I will also add the <DISABLE_USB_SERIAL> flag.

[majbthrd]

I'm the author of pico-debug. Just for context: pico-debug is an alternative to picoprobe; only one RP2040 is needed (unlike two for picoprobe) and there is no added cabling.

As I originally envisioned it, the user programs their app into the RP2040 as normal and only loads pico-debug into RAM if and when they need it for debugging. However, there is no technical reason why you couldn't incorporate it into the user image if you wanted to.

Allowing the user to disable USB in the user app if they don't need it sounds like a great first step.

Perhaps integration of pico-debug could be a future plan if there is interest? I can propose ways of integrating it once I've had a chance to look at the arduino-pico code.

[tvlad1234]

My idea of integrating pico-debug is to add a button or menu option to upload it to the board, and then to start the debugging session as usual.

[earlephilhower]

Cool, @majbthrd ! I think I saw something about pico-debug on HAD or elsewhere, but didn't really go into it as the 1st thing I did when I got my Picos was hardwire one up for Picoprobe duty and soldered in SWD headers on the others.

I'll take a look at the pico-debug code, too, over the weekend. My gut says building it as a .a that's distributed in the /lib directory is the best way (lets you use plain pico-sdk and CMake to build the pico-debug binary, no Arduino crud required), and having an ifdef'd call to it's startup routine in main.cpp is all that's really needed to get things off the ground.

[majbthrd]

@earlephilhower, I think your gut is right, but I'm beginning to remember why I originally soured on the approach of a built-in image.

The problem with having the user main startup invoke the debugger is that it would reset and restart the debugger every time the user code ran that code (which would be every time the user restarted their code, which happens often in debugging). That pulls the rug out from under the IDE. The advantage of the existing approach is that once pico-debug is invoked, it does its own thing without being coupled to the user code.

[earlephilhower]

Oh, I wasn't suggesting any changes to the way pico-debug runs now, mybad.

Actually, don't you intercept the CRT0.S code as well? Things like .bss zeroing, copying from flash to .data, etc.?

In any case, I'm sure judicious use of #ifdef to rename main() or weakref to have the linker do the magic, can make it work.

[majbthrd]

No worries @earlephilhower ; I didn't think that. To answer your question, at the moment, pico-debug is a stand-alone RAM-only application (that has its own crt0.s, its own .bss, etc. and does NOT use pico-sdk so as to use a smaller memory footprint.)

With regard possible future features, what I'm thinking of is some sort of addition to the arduino-pico main routine that does some sort of checksum of the pico-debug memory region and checks whether Core1 is already running. If it only starts up pico-debug when the user code is run for the first time, it won't "poke the bear with a stick" unnecessarily.

Back to the here and now, for the existing and well-trodden pico-debug usage, no modifications should be needed other than arduino-pico offering the user app a chance to not use USB.

[earlephilhower]

Release 1.9.2 enabled 1st-class pico-debug support from the menus, so this should be taken care of.