Issues with compiling, getting to recognize serial output

[billj324]

UPDATE: need someone to build for pico_w. All attempts fail due to not knowing where all configuration files stem from, where they go, and what they pertain to. setting in VScode vs cmake for windows vs the myriad of possible locations that I still cannot keep track of. Is it me, or does VScode make life harder than if one were to just use command lines?

PLEASE PLEASE JUST BUILD THE FIRMWARE AND PLACE INTO THE RELEASES

[lurch]

See Appendix A. of https://datasheets.raspberrypi.com/pico/getting-started-with-pico.pdf and https://www.raspberrypi.com/documentation/microcontrollers/debug-probe.html#updating-the-firmware-on-the-debug-probe

[billj324]

first off, I want to appologize for venting my frustrations. you dont deserve that. I've followed everything in those PDFs verbatim and still... a (would you say...) plethora of issues. Lets start out by listing my env: Windows 11 w/msys64/mingw64. I'm doing this completely outside of VScode, because there are a littany of issues with that, including it not passing my pico_w correctly (didnt wanna mess w it rn because I would rather avoid a layer and just use command lines. I've struggled with environment variable like crazy with this one. doing the typical export command to set the sdk path IS not only inconsistent, but flawed in mingw64, due to inconsistent behavior within same mingw session, vs reloading it, v.s. rebooting computer/reloading mingw I've dug through mountains of documentation to find the most incomplete documentation on the issue or the behavior does NOT match documentation. For instance, I still cant find where to permanently change the pico-sdk-path so that opening mingw64 has it set right, despite export -p showing it is in fact set right, running cmake persistently tries to pick it up from program files/pico-sdk-1.5.x. setting it with export is only per-session. I set it in the windows env, upon reboot mingw64 now lists it properly within export -p. HOWEVER, cmake still doesnt get it. SO:

cmake -DPICO_SDK_PATH="/c/pico/pico_sdk2" -DDEBUG_ON_PICO=ON -DPICO_BOARD=pico_w .. this finally works, heres the output:

Target board (PICO_BOARD) is 'pico_w'. Using board configuration from /c/pico/pico_sdk2/src/boards/include/boards/pico_w.h Defaulting platform (PICO_PLATFORM) to 'rp2040' based on PICO_BOARD setting. -- Defaulting build type to 'Release' since not specified. Defaulting compiler (PICO_COMPILER) to 'pico_arm_cortex_m0plus_gcc' since not specified. Configuring toolchain based on PICO_COMPILER 'pico_arm_cortex_m0plus_gcc' Defaulting PICO_GCC_TRIPLE to 'arm-none-eabi' -- The C compiler identification is GNU 13.3.0 -- The CXX compiler identification is GNU 13.3.0 -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working C compiler: /mingw64/bin/arm-none-eabi-gcc.exe - skipped -- Detecting C compile features -- Detecting C compile features - done -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Check for working CXX compiler: /mingw64/bin/arm-none-eabi-g++.exe - skipped -- Detecting CXX compile features -- Detecting CXX compile features - done -- The ASM compiler identification is GNU -- Found assembler: /mingw64/bin/arm-none-eabi-gcc.exe Build type is Release -- Found Python3: /mingw64/bin/python3.11.exe (found version "3.11.9") found components: Interpreter TinyUSB available at /c/pico/pico_sdk2/lib/tinyusb/src/portable/raspberrypi/rp2040; enabling build support for USB. BTstack available at /c/pico/pico_sdk2/lib/btstack cyw43-driver available at /c/pico/pico_sdk2/lib/cyw43-driver Pico W Bluetooth build support available. lwIP available at /c/pico/pico_sdk2/lib/lwip Pico W Wi-Fi build support available. mbedtls available at /c/pico/pico_sdk2/lib/mbedtls -- Configuring done (4.7s) -- Generating done (1.6s) -- Build files have been written to: /c/pico/debugprobe/build

You can see that it referenced everything correctly. is: pico_arm_cortex_m0plus_gcc correct? or is that the wrong toolchain or configuration?

when I run make -j4:

C:/pico/debugprobe/build/generated/pico_base/pico/config_autogen.h:7:10: fatal error: /c/pico/pico_sdk2/src/boards/include/boards/pico_w.h: No such file or directory 7 | #include "/c/pico/pico_sdk2/src/boards/include/boards/pico_w.h" | ^~~~~~~~~~~~~~ compilation terminated.

I can, with great certainty, say the file DOES exist. I get this even when specifying: -DPICO_BOARD=pico, but complaining pico.h cannot be found. I'm so close to making this work I can SMELL it. this is becoming a head scratcher.
Can I specify the header file directly, with say -DPICO_BOARD="/c/pico/pico_sdk2/src/board/include/pico_w.h"? EDIT: tried this by subbing pico_w in the command line with the above statement: doesnt work or is there another issue I'm not understanding correctly?

[kilograham]

Cc @will-v-pi

[billj324]

as another update, vscode keeps trying to use ninja, but I followed the instructions for manually entering it into perferences>settings>cmake extension > cmake:generator > "NMake Makefiles" w/o quotes

[lurch]

ping also @nathan-contino in case the documentation needs updating.

is: pico_arm_cortex_m0plus_gcc correct?

Yes. Pico W uses the same RP2040 chip as the Pico, and the CPU-cores in the RP2040 are Arm Cortex M0+ (see the Introduction chapter in https://datasheets.raspberrypi.com/rp2040/rp2040-datasheet.pdf ).

as another update, vscode keeps trying to use ninja, but I followed the instructions for manually entering it into perferences>settings>cmake extension > cmake:generator > "NMake Makefiles" w/o quotes

We used to recommend that in an earlier version of the Getting Started guide, because ninja on Windows had a bug; but that bug has since been fixed and so https://datasheets.raspberrypi.com/pico/getting-started-with-pico.pdf no longer talks about changing the CMake Generator in VSCode. Please check that you're not still using an old version of the PDF? (at the time of writing, the latest version of that PDF says "build-date: 2024-08-21")

[lurch]

C:/pico/debugprobe/build/generated/pico_base/pico/config_autogen.h:7:10: fatal error: /c/pico/pico_sdk2/src/boards/include/boards/pico_w.h: No such file or directory 7 | #include "/c/pico/pico_sdk2/src/boards/include/boards/pico_w.h" | ^~~~~~~~~~~~~~ compilation terminated.

I can, with great certainty, say the file DOES exist.

I'm just guessing here (I don't use Windows myself), but I wonder if part of the problem might be that some part of your system is trying to use MinGW-style paths (/c/pico/blah) but another part of your system is trying to use Windows-style paths (C:\pico\blah) ? :man_shrugging:

[will-v-pi]

Firstly, the debugprobe_on_pico firmware should work fine on Pico W, so there’s no need to compile it from source. The only thing that wouldn’t work would be the LED, but that wouldn’t be fixed by just setting PICO_BOARD=pico_w as the project uses its own pin definitions, and would need to change the LED flashing code similar to the blink example in pico-examples to work on both Pico and Pico W.

Secondly, I just tried importing this repository and compiling it with the VS Code extension and didn’t encounter any issues, so it should work fine other than the PICO_BOARD setting - the extension requires a set(PICO_BOARD …) line in the CMakeLists.txt file for that to work, which this project doesn’t have. We’ll look into adding that into the import project wizard.

perferences>settings>cmake extension > cmake:generator > "NMake Makefiles"

This setting is ignored by the VS Code extension, as this is a setting for the CMakeTools extension and we compile separately from that extension. You can enable CMakeTools in our extension - there’s some instructions in issue 37 and we will add them to the readme too

C:/pico/debugprobe/build/generated/pico_base/pico/config_autogen.h:7:10: fatal error: /c/pico/pico_sdk2/src/boards/include/boards/pico_w.h: No such file or directory 7 | #include "/c/pico/pico_sdk2/src/boards/include/boards/pico_w.h" | ^~~~~~~~~~~~~~ compilation terminated.

I can, with great certainty, say the file DOES exist.

This does look like the primary issue - these generated paths should be C:/ not /c/ - you could try specifying PICO_SDK_PATH with C:/ instead and see if that fixes it? You should also be able to compile from PowerShell using mingw64 rather than using the msys terminal, which is likely to work better - you may need to add your mingw64 tools to your path to make this work.

Alternatively, for compiling from the command line on Windows, we would strongly recommend using WSL2 instead - setting up everything in WSL2 is much simpler than using msys.

[billj324]

before going to sleep, I processed it for a bit, the conclusion I came to was the same, its having issues with the path interpolation. I'm on windows by choice right now, this laptop is the most mobile machine I have so out of convenience, I'm using it. I have two Linux-native machines, looks like I'm going to switch, as I see it being more sustainable with fewer issues. I was just hoping I could master this env, but the issues seem endless. my final attempt at this will come after spending some time to master the difference to fill out my knowledge. I will give the released firmware one more try, I was hoping to get the LED working so I had some sign of life from the picow, if that fails, I'll swith to another (I have the pins soldered to eliminate that vector of failure). Thank you all. not going to give up on this, despite the frustration, I still find the challenge fun I do find it interesting that its just that path its having a fit about as there are other references in the output that use the address just fine. very curious, I'm logging my steps meticulously, and keeping the sources "clean" by starting fresh with each attempt.

[billj324]

got the debug output from openOCD. Its not getting response from the target picow anyone spot anything? oocdoutpt.txt

[billj324]

I have good news and bad news, I was able to get it to receive output from the target picow, through the UART on the debugprobe picow. I can see the outputs in both putty and the serial monitor now. the issue with openocd appears to still remain. This is no longer your issue I believe. The problem now lies with openOCD. Thank you all.

[lurch]

UPDATE: need someone to build for pico_w.

Are you happy to close this issue as a duplicate of #41 ?

[Neril]

Please update the uf2 compilation instructions to reference Ninja as a possible build tool. I'm probably unusual in using Windows / VS Code, but it took me a while to work out that cmake had generated a set of ninja files, not the Makefile that the instructions assume, and therefore the instructions were not working.

As it happens, I was also building for Pico2, which didn't even mention running make after cmake, so I had incorrectly concluded that the "make" line above was a typo.