Update P.IO toolchain references to GitHub release

[earlephilhower]

Absolutely, we can have reference abitrary direct download links to a .zip or .tar.gz instead (if it already has a package.json in), same for referencing repos (or even different branches of repos). I already do that in stuff like platform-ch32v. That's definitely a thing we can pull in at the next platform update, but it should not be causing this specific issue.

Originally posted by @maxgerhardt in #1647 (reply in thread)

[earlephilhower]

@maxgerhardt the pico-quick-toolchain releases do have package.json files, so I think it's just a matter of working your magic to point to the releases in your platform config files. This should let P.IO move up to the GCC 12.3 chain.

[maxgerhardt]

Dang it. The GCC/GDB 12.2 version seems to have the same error as I've recently encountered in a forum post: It seemes not possible to start GDB in "pipe" mode. (OpenOCD is started with -gdb_port pipe and the execution of that OpenOCD instance is piped into GDB, I think).

So while I can compile firmwares perfectly fine with the latest toolchain package on Windows using

platform_packages =
   toolchain-rp2040-earlephilhower@https://github.com/earlephilhower/pico-quick-toolchain/releases/download/2.0.0-a/x86_64-w64-mingw32.arm-none-eabi-d3d2e6b.230824.zip

, the project is undebuggable. Same per platformio/platform-ststm32#720 (comment).

I'm not yet sure how to resolve that, whether it's a GDB (compile) option or broken in just GDB 12 (regression?), or PlatformIO is doing something wrong.. but it did work with the previous GDB version just fine.

[earlephilhower]

Do you have the exact command line being run? And is it only Windows like in the ref'd bug or everywhere?

No options have changed GCC10->12 (or been touched in a year):

a02109cd (Earle F. Philhower, III 2018-12-11 10:01:24 -0800 237) # GCC et. al configure options
30b0fd07 (Earle F. Philhower, III 2018-12-10 16:35:35 -0800 238) configure  = --prefix=$(call install,$(1))
a02109cd (Earle F. Philhower, III 2018-12-11 10:01:24 -0800 239) configure += --build=$(shell gcc -dumpmachine)
30b0fd07 (Earle F. Philhower, III 2018-12-10 16:35:35 -0800 240) configure += --host=$(call host,$(1))
5f3351f4 (Earle F. Philhower, III 2021-02-02 22:01:42 -0800 241) configure += --target=$(ARCH)
30b0fd07 (Earle F. Philhower, III 2018-12-10 16:35:35 -0800 242) configure += --disable-shared
a02109cd (Earle F. Philhower, III 2018-12-11 10:01:24 -0800 243) configure += --with-newlib
a02109cd (Earle F. Philhower, III 2018-12-11 10:01:24 -0800 244) configure += --enable-threads=no
a02109cd (Earle F. Philhower, III 2018-12-11 10:01:24 -0800 245) configure += --disable-__cxa_atexit
a02109cd (Earle F. Philhower, III 2018-12-11 10:01:24 -0800 246) configure += --disable-libgomp
a02109cd (Earle F. Philhower, III 2018-12-11 10:01:24 -0800 247) configure += --disable-libmudflap
a02109cd (Earle F. Philhower, III 2018-12-11 10:01:24 -0800 248) configure += --disable-nls
ed6d983b (Earle F. Philhower, III 2022-02-12 10:49:08 -0800 249) configure += --without-python
30b0fd07 (Earle F. Philhower, III 2018-12-10 16:35:35 -0800 250) configure += --disable-bootstrap
a02109cd (Earle F. Philhower, III 2018-12-11 10:01:24 -0800 251) configure += --enable-languages=c,c++
5dd03b9b (Earle F. Philhower, III 2022-06-07 14:03:44 -0700 252) configure += --disable-lto
241b4048 (Earle F. Philhower, III 2018-12-14 13:43:21 -0800 253) configure += --enable-static=yes
30b0fd07 (Earle F. Philhower, III 2018-12-10 16:35:35 -0800 254) configure += --disable-libstdcxx-verbose
47de5543 (Earle F. Philhower, III 2021-02-06 16:08:54 -0800 255) configure += --disable-decimal-float
c6a64691 (Earle F. Philhower, III 2022-06-04 16:11:56 -0700 256) configure += --with-cpu=cortex-m0plus
c6a64691 (Earle F. Philhower, III 2022-06-04 16:11:56 -0700 257) configure += --with-no-thumb-interwork

[earlephilhower]

Little niggle in the back of my head...if this is Windows only, the "pipe" part of the problem may be an MSYS2 or MingW64 problem and not related to GDB or its configuration at all. I'm sure they need to do lots of magic to implement things like UNIX pipes on WIN32...

[maxgerhardt]

I'll look through the source code of the PlatformIO core later but per this it seems plausible to me that first they do arm-none-eabi-gdb <path to firmware.elf> and in that GDB shell they do that target extended-remote | openocd -c "gdb_port pipe" -f ... command. So it should be straight forward to test on the commandline without PlatformIO.

I'll also test this on Linux. Plus with the older GDB versions as a sanity check.

[maxgerhardt]

Yes. This is reproducable:

With GDB 8.2.50 of the previous toolchain:

>arm-none-eabi-gdb.exe firmware.elf
target extended-remote | "C:/Users/Max/Downloads/x86_64-w64-mingw32.openocd-4d87f6dca.230824/openocd/bin/openocd.exe" -c "gdb_port pipe" -s "C:/Users/Max/Downloads/x86_64-w64-mingw32.openocd-4d87f6dca.230824/openocd/share/openocd" -f "interface/cmsis-dap.cfg" -f "target/rp2040.cfg"
Remote debugging using | "C:/Users/Max/Downloads/x86_64-w64-mingw32.openocd-4d87f6dca.230824/openocd/bin/openocd.exe" -c "gdb_port pipe" -s "C:/Users/Max/Downloads/x86_64-w64-mingw32.openocd-4d87f6dca.230824/openocd/share/openocd" -f "interface/cmsis-dap.cfg" -f "target/rp2040.cfg"
Open On-Chip Debugger 0.12.0-g4d87f6dca (2023-08-24-20:49)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
Info : Hardware thread awareness created
Info : Hardware thread awareness created
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Warn : An adapter speed is not selected in the init scripts. OpenOCD will try to run the adapter at the low speed (100 kHz)
Warn : To remove this warnings and achieve reasonable communication speed with the target, set "adapter speed" or "jtag_rclk" in the init scripts.
Info : Using CMSIS-DAPv2 interface with VID:PID=0x2e8a:0x000c, serial=E66038B713193E30
Info : CMSIS-DAP: SWD supported
Info : CMSIS-DAP: Atomic commands supported
Info : CMSIS-DAP: Test domain timer supported
Info : CMSIS-DAP: FW Version = 2.0.0
Info : CMSIS-DAP: Interface Initialised (SWD)
Info : SWCLK/TCK = 0 SWDIO/TMS = 0 TDI = 0 TDO = 0 nTRST = 0 nRESET = 0
Info : CMSIS-DAP: Interface ready
Info : clock speed 100 kHz

But on the new GDB 12.0.50 version:

error starting child process '| "C:/Users/Max/Downloads/x86_64-w64-mingw32.openocd-4d87f6dca.230824/openocd/bin/openocd.exe" -c "gdb_port pipe" -s "C:/Users/Max/Downloads/x86_64-w64-mingw32.openocd-4d87f6dca.230824/openocd/share/openocd" -f "interface/cmsis-dap.cfg" -f "target/rp2040.cfg"': CreateProcess: No such file or directory

I also noticed in the working v8 version it was very picky with / vs \ and would spit out the same CreateProcess error if I used \ in the path for OpenOCD instead of ´/`, but in GDB 12, both don't work. Time to test on Linux.

[maxgerhardt]

On Ubuntu 22 this does work first try with GDB 12 + newest OpenOCD (i.e. same toolchain versioning as tried + failed on Windows):

(gdb) target extended-remote | ~/new_gdb/openocd/bin/openocd -c "gdb_port pipe" -s ~/new_gdb/openocd/share/openocd  -f "interface/cmsis-dap.cfg" -f "target/rp2040.cfg"
Remote debugging using | ~/new_gdb/openocd/bin/openocd -c "gdb_port pipe" -s ~/new_gdb/openocd/share/openocd  -f "interface/cmsis-dap.cfg" -f "target/rp2040.cfg"
Open On-Chip Debugger 0.12.0-g4d87f6dca (2023-08-24-21:19)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
Info : Hardware thread awareness created
Info : Hardware thread awareness created
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Warn : An adapter speed is not selected in the init scripts. OpenOCD will try to run the adapter at the low speed (100 kHz)
Warn : To remove this warnings and achieve reasonable communication speed with the target, set "adapter speed" or "jtag_rclk" in the init scripts.
Info : Using CMSIS-DAPv2 interface with VID:PID=0x2e8a:0x000c, serial=E66038B713193E30
Info : CMSIS-DAP: SWD supported
Info : CMSIS-DAP: Atomic commands supported
Info : CMSIS-DAP: Test domain timer supported
Info : CMSIS-DAP: FW Version = 2.0.0
Info : CMSIS-DAP: Interface Initialised (SWD)
Info : SWCLK/TCK = 0 SWDIO/TMS = 0 TDI = 0 TDO = 0 nTRST = 0 nRESET = 0
Info : CMSIS-DAP: Interface ready
Info : clock speed 100 kHz
Info : SWD DPIDR 0x0bc12477, DLPIDR 0x00000001
Info : SWD DPIDR 0x0bc12477, DLPIDR 0x10000001
Info : [rp2040.core0] Cortex-M0+ r0p1 processor detected
Info : [rp2040.core0] target has 4 breakpoints, 2 watchpoints
Info : [rp2040.core1] Cortex-M0+ r0p1 processor detected
Info : [rp2040.core1] target has 4 breakpoints, 2 watchpoints
Info : starting gdb server for rp2040.core0 on pipe
Info : accepting 'gdb' connection from pipe
Info : Found flash device 'win w25q16jv' (ID 0x001540ef)
Info : RP2040 B0 Flash Probe: 2097152 bytes @0x10000000, in 32 sectors

Info : New GDB Connection: 1, Target rp2040.core0, state: halted
Warn : keep_alive() was not invoked in the 1000 ms timelimit. GDB alive packet not sent! (1011 ms). Workaround: increase "set remotetimeout" in GDB
[rp2040.core0] halted due to breakpoint, current mode: Thread 
xPSR: 0x61000000 pc: 0x100055f6 msp: 0x20041f90
[rp2040.core1] halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0x00000178 msp: 0x20041f00
warning: No executable has been specified and target does not support
determining executable automatically.  Try using the "file" command.
warning: multi-threaded target stopped without sending a thread-id, using first non-exited thread
0x100055f6 in ?? ()
(gdb) 

So this is indeed only Windows specific. Hm. Let's see if I can't cross-compile GDB 13 to check if it's still a bug..

[maxgerhardt]

Or, instead of going through all that bug hunting and regression reporting, I could just modify my platform code so that it does return a "debug port" item, then instead of opening a pipe it will try to bind a regular TCP port of my choice (like 3333) and connect to that. But that is praying then that some other program doesn't bind it already.

https://github.com/platformio/platformio-core/blob/091c96eb078964dd18eaa1cb9d84ee0079584e53/platformio/debug/process/server.py#L63-L81

Or, why not do the workaround now to check if it works and report it anyways if it still occurs for GDB 13.

[maxgerhardt]

.. Sadly that does not work in an automated way since, if I give it port in the debug tool definition, it thinks the server was already started externally and just needs to conenct to it. So the user would have to start OpenOCD themselves. Not very friendly. But doing that at least proves it's in general perfectly capable of working with GDB 12, just not in pipe mode.

[earlephilhower]

Is there anything I can try to help out here? I unfortunately don't use P.IO outside of building my Marlin instances for my CNC and 3D Printer, but I can try toolchain build changes...

[maxgerhardt]

I'd need a for Windows / MinGW crosscompiled GDB13.2 (https://ftp.gnu.org/gnu/gdb/?C=M;O=D) version, that would help out a lot.

[earlephilhower]

GCC/GDB 13.2: https://github.com/earlephilhower/pico-quick-toolchain/releases/tag/6.6.6-6

Uses binutils' tag "gdb-13.2-release" because 2_41 had GDB 14 when built. GCC tag is "gcc-13.2.0"

[maxgerhardt]

Oh wow. This instantly works without any modification to platform-raspberrypi for the debug server config. Just a pure package exchange.

platform_packages =
   toolchain-rp2040-earlephilhower@https://github.com/earlephilhower/pico-quick-toolchain/releases/download/6.6.6-6/x86_64-w64-mingw32.arm-none-eabi-d3d2e6b.230911.zip

I'd love it if we could use this toolchain instead? Do I understand it correctly that GCC is also upgraded von GCC12 to GCC13?

[earlephilhower]

Yes, I bumped up GCC to 13.2 to match GDB 13.2. HAven't actually guilt anything with the new compiler, though, so no idea if things in the core are busted or more warnings are appearing.

This seems to indicate it's a GCC 12.x regression and not related to anything on our ends. Great news! No build or configure changes other than the git checkout tag were done.

If it's workable I think I'd like to run GCC 12.3 with the updated binutils GDB 13.2 tag, instead of really bumping to the bleeding edge of GCC. I might paranoid, but I prefer for other people to find and fix compiler bugs before I hit them. 😆

[earlephilhower]

@maxgerhardt could you give this release a test w/GDB integration? Only Win32/64/Linux built, but it keeps GCC @ 12.3 and bumbs up all binutils (GDB plus other tools) to gdb-13.2-release. https://github.com/earlephilhower/pico-quick-toolchain/releases/tag/6.6.6-7

#1705 shows it building CI OK (except for Mac which was not built for testing). I'll try some GDB testing after work.

[earlephilhower]

Actually, please try with this full build tools release pre-staged for merge: https://github.com/earlephilhower/pico-quick-toolchain/releases/tag/2.1.0-a

[maxgerhardt]

The 2.1.0-a toolchain still works equivalently perfectly.

platform_packages =
   toolchain-rp2040-earlephilhower@https://github.com/earlephilhower/pico-quick-toolchain/releases/download/2.1.0-a/x86_64-w64-mingw32.arm-none-eabi-d3d2e6b.230911.zip

[earlephilhower]

Thanks, can you update your P.IO integration to point to that 2.1.0-a ? I have made that the latest release and would like to get a clean P.IO run before merging the update in #1706 .

[maxgerhardt]

Let's see how maxgerhardt/platform-raspberrypi@ac952da goes in my CI run https://github.com/maxgerhardt/platform-raspberrypi/actions/runs/6176895013/job/16766821370..

Edit: First results do seem positive..

[maxgerhardt]

So that actually worked on the platform-raspberrypi side. I pushed another update to use the latest arduino-pico core and updated board definitions. I expect this run to also go through normally.

Can you rerun CI for #1706?

[earlephilhower]

Do I need to change anything in this repo to get the update? I re-ran CI and it ended up pulling the 10.3 toolchain again. https://github.com/earlephilhower/arduino-pico/actions/runs/6153488298/job/16767773263

The reason it's failing is the new binutils linker option needed to avoid a spurious warning on linkage, nothing related to GCC or GDB.

The warning shows in your runs (non-fatal, but a warning that will show on every build w/o the new options)

 /home/runner/.platformio/packages/toolchain-rp2040-earlephilhower/bin/../lib/gcc/arm-none-eabi/12.3.0/../../../../arm-none-eabi/bin/ld: warning: .pio/build/pico_earle/firmware.elf has a LOAD segment with RWX permissions

[maxgerhardt]

The github actions file is pointing at the latest platform link, however, I think the cache is still hot and the previous restore (and the fact that the platform URL is always the same) it didn't trigger a fresh platform install..

https://github.com/earlephilhower/arduino-pico/blob/master/.github/workflows/pull-request.yml#L195-L209

So two possibilities:

• Delete the caches via the supposedly existing UI https://github.com/earlephilhower/arduino-pico/actions/caches
• Modify https://github.com/earlephilhower/arduino-pico/blob/master/.github/workflows/pull-request.yml#L208 to include the latest hash so that it's forced to do the install, i.e.,

        pio pkg install --global --platform https://github.com/maxgerhardt/platform-raspberrypi.git#b036e8727e9f13b2a9ff4e893970a0097d3f2c32

[earlephilhower]

Clearing caches fixed it. I'm doing a 3.5.0 release since it's a toolchain bump but we should be good now. Thx!

[maxgerhardt]

Great. Just FYI, the "Signed OTA example" CI run shows a warning regarding std::map and GCC 7.1 usage?

In file included from /home/runner/.platformio/packages/toolchain-rp2040-earlephilhower/arm-none-eabi/include/c++/12.3.0/map:60,
                 from /home/runner/work/arduino-pico/arduino-pico/libraries/WiFi/src/WiFiClass.cpp:29:
/home/runner/.platformio/packages/toolchain-rp2040-earlephilhower/arm-none-eabi/include/c++/12.3.0/bits/stl_tree.h: In member function 'std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>::iterator std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>::_M_emplace_hint_unique(const_iterator, _Args&& ...) [with _Args = {const std::piecewise_construct_t&, std::tuple<long long unsigned int&&>, std::tuple<_cyw43_ev_scan_result_t&>}; _Key = long long unsigned int; _Val = std::pair<const long long unsigned int, _cyw43_ev_scan_result_t>; _KeyOfValue = std::_Select1st<std::pair<const long long unsigned int, _cyw43_ev_scan_result_t> >; _Compare = std::less<long long unsigned int>; _Alloc = std::allocator<std::pair<const long long unsigned int, _cyw43_ev_scan_result_t> >]':
/home/runner/.platformio/packages/toolchain-rp2040-earlephilhower/arm-none-eabi/include/c++/12.3.0/bits/stl_tree.h:2459:7: note: parameter passing for argument of type 'std::_Rb_tree<long long unsigned int, std::pair<const long long unsigned int, _cyw43_ev_scan_result_t>, std::_Select1st<std::pair<const long long unsigned int, _cyw43_ev_scan_result_t> >, std::less<long long unsigned int>, std::allocator<std::pair<const long long unsigned int, _cyw43_ev_scan_result_t> > >::const_iterator' changed in GCC 7.1

[earlephilhower]

Ah, one add'l P.IO GCC flag needed. I added it to platform.txt but must've forgotten it in the pio-build.pu. Will fix. #1709

[yamaan93]

I wanted to ask a clarifying question in this thread since I've come across the issue with the debugger using the version of the toolchain in the pio index. currently I need version >=12 to get my project to compile using gnu++20, (or 2a as listed in my build flags), and that worked fine in the version in the index, but I've tried changing to pico-quick-toolchain by changing my platform_packages line to

platform_packages = toolchain-gccarmnoneeabi-earlephilhower@ https://github.com/earlephilhower/pico-quick-toolchain/releases/download/2.1.0-a/i686-w64-mingw32.arm-none-eabi-d3d2e6b.230911.zip

However that doesn't seem to do what is intended and from my terminal output I can see that it's using:

 PACKAGES:
 - toolchain-gccarmnoneeabi @ 1.70201.0 (7.2.1)

So I'm not quite sure how to correctly get my project to use the updated toolchain here.

[maxgerhardt]

Well the package this provides is toolchain-gccarmnoneeabi-earlephilhower, not toolchain-gccarmnoneeabi. Also the Pico toolchain is very much custom-configured for only Cortex-M0+, so not applicable to your Cortex-M7 ad M4. So let's keep this conversion in https://community.platformio.org/t/unable-to-debug-stm32h723-nucleo-board/35826.