Arduino-Pico (Earlephilhower) support, PicoProbe Debugging

maxgerhardt commented 2 years ago

Massive upgrade.

Add support for building for https://github.com/earlephilhower/arduino-pico
As in the style of platform-ststm32, boards that can be used with both cores can be switched to the other core using board_build.core = earlephilhower
Integrates with my already merged builder script at https://github.com/earlephilhower/arduino-pico/blob/master/tools/platformio-build.py
Added all Arduino-Pico boards (Earle auto-gen'ed them through https://github.com/earlephilhower/arduino-pico/blob/master/tools/makeboards.py)
Arduino core must use toolchain and tools from https://github.com/earlephilhower/pico-quick-toolchain/releases, which are finally in the registry
- no more platform_packages injection platformio.ini needed, all tools (except framework) sourced from registry
Replace outdated platformio/tool-openocd-raspberrypi (1 year old, before picoprobe merge) with earlephilhower/tool-openocd-rp2040-earlephilhower -- works for all frameworks and cores (also the mbed-os core)
Added support for LittleFS filesystem building + uploading through picotool and OpenOCD (picoprobe etc.); Arduino-Pico core supports LittleFS
Added and tested Picoprobe support for both ArduinoCore-mbed and Arduino-Pico, works great
Reduced default debugging and OpenOCD upload speed to 1000kHz, the 5000kHz was giving me verification errors
Add Arduino-Pico examples to CI
Reprogrammed upload_protocol = mbed to make more sense, it previously tried to upload the .bin file to the drive instead of the .uf2 file
Update SVD file with latest from https://github.com/raspberrypi/pico-sdk/blob/master/src/rp2040/hardware_regs/rp2040.svd

grafik

Test at will with

[env]
platform = https://github.com/maxgerhardt/platform-raspberrypi.git
framework = arduino
board_build.core = earlephilhower
board_build.filesystem_size = 0.5m

[env:pico]
board = pico
; if using picoprobe SWD upload / debugging
;upload_protocol = picoprobe
;debug_tool = picoprobe
; note: newer PicoProbe firmwares emulate a CMSIS-DAP, so you
; use "cmsis-dap" as upload_protocol and debug_tool.
; for more info see docs https://arduino-pico.readthedocs.io/en/latest/platformio.html

ToDo (all done at the moment of writing):

create PR for platformio-docs, previous docs at https://arduino-pico.readthedocs.io/en/latest/platformio.html are outdated
create PR for arduino-pico docs as docs is now outdated
fix https://github.com/earlephilhower/arduino-pico/issues/612
upload / make Earle upload framework-arduinopico package (after fix of course)

maxgerhardt commented 2 years ago

And please squash upon merge, otherwise you have more than 43 commits from me.

sstaub commented 2 years ago

Build failed on maOS.

maxgerhardt commented 2 years ago

You are using an old platform version. CLI -> pio platform update https://github.com/maxgerhardt/platform-raspberrypi.git.

sstaub commented 2 years ago

Ok, I can now compile but I get some ugly warning and errors.

maxgerhardt commented 2 years ago

Can you Cmd+Shift+P -> Rebuild Intellisense and upload the .vscode/c_cpp_properties.json to https://pastebin.com/?

sstaub commented 2 years ago

Here the cpp.json // // !!! WARNING !!! AUTO-GENERATED FILE! // PLEASE DO NOT MODIFY IT AND USE "platformio.ini": // https://docs.platformio.org/page/projectconf/section_env_build.html#build-flags // { "configurations": [ { "name": "PlatformIO", "includePath": [ "/Users/sstaub/Dateien/Development/Raspberry Pico/blinky2/include", "/Users/sstaub/Dateien/Development/Raspberry Pico/blinky2/src", "/Users/sstaub/.platformio/packages/framework-arduinopico/cores/rp2040", "/Users/sstaub/.platformio/packages/framework-arduinopico/cores/rp2040/api/deprecated", "/Users/sstaub/.platformio/packages/framework-arduinopico/cores/rp2040/api/deprecated-avr-comp", "/Users/sstaub/.platformio/packages/framework-arduinopico/tools/libpico", "/Users/sstaub/.platformio/packages/framework-arduinopico/variants/rpipico", "/Users/sstaub/.platformio/packages/framework-arduinopico/libraries/EEPROM", "/Users/sstaub/.platformio/packages/framework-arduinopico/libraries/ESP8266SdFat/src", "/Users/sstaub/.platformio/packages/framework-arduinopico/libraries/FreeRTOS/src", "/Users/sstaub/.platformio/packages/framework-arduinopico/libraries/I2S/src", "/Users/sstaub/.platformio/packages/framework-arduinopico/libraries/Keyboard/src", "/Users/sstaub/.platformio/packages/framework-arduinopico/libraries/LittleFS/src", "/Users/sstaub/.platformio/packages/framework-arduinopico/libraries/Mouse/src", "/Users/sstaub/.platformio/packages/framework-arduinopico/libraries/PDM/src", "/Users/sstaub/.platformio/packages/framework-arduinopico/libraries/SD/src", "/Users/sstaub/.platformio/packages/framework-arduinopico/libraries/SDFS/src", "/Users/sstaub/.platformio/packages/framework-arduinopico/libraries/SPI/src", "/Users/sstaub/.platformio/packages/framework-arduinopico/libraries/Servo/src", "/Users/sstaub/.platformio/packages/framework-arduinopico/libraries/Wire/src", "/Users/sstaub/.platformio/packages/framework-arduinopico/libraries/rp2040", "" ], "browse": { "limitSymbolsToIncludedHeaders": true, "path": [ "/Users/sstaub/Dateien/Development/Raspberry Pico/blinky2/include", "/Users/sstaub/Dateien/Development/Raspberry Pico/blinky2/src", "/Users/sstaub/.platformio/packages/framework-arduinopico/cores/rp2040", "/Users/sstaub/.platformio/packages/framework-arduinopico/cores/rp2040/api/deprecated", "/Users/sstaub/.platformio/packages/framework-arduinopico/cores/rp2040/api/deprecated-avr-comp", "/Users/sstaub/.platformio/packages/framework-arduinopico/tools/libpico", "/Users/sstaub/.platformio/packages/framework-arduinopico/variants/rpipico", "/Users/sstaub/.platformio/packages/framework-arduinopico/libraries/EEPROM", "/Users/sstaub/.platformio/packages/framework-arduinopico/libraries/ESP8266SdFat/src", "/Users/sstaub/.platformio/packages/framework-arduinopico/libraries/FreeRTOS/src", "/Users/sstaub/.platformio/packages/framework-arduinopico/libraries/I2S/src", "/Users/sstaub/.platformio/packages/framework-arduinopico/libraries/Keyboard/src", "/Users/sstaub/.platformio/packages/framework-arduinopico/libraries/LittleFS/src", "/Users/sstaub/.platformio/packages/framework-arduinopico/libraries/Mouse/src", "/Users/sstaub/.platformio/packages/framework-arduinopico/libraries/PDM/src", "/Users/sstaub/.platformio/packages/framework-arduinopico/libraries/SD/src", "/Users/sstaub/.platformio/packages/framework-arduinopico/libraries/SDFS/src", "/Users/sstaub/.platformio/packages/framework-arduinopico/libraries/SPI/src", "/Users/sstaub/.platformio/packages/framework-arduinopico/libraries/Servo/src", "/Users/sstaub/.platformio/packages/framework-arduinopico/libraries/Wire/src", "/Users/sstaub/.platformio/packages/framework-arduinopico/libraries/rp2040", "" ] }, "defines": [ "PLATFORMIO=60003", "ARDUINO_RASPBERRY_PI_PICO", "ARDUINO_ARCH_RP2040", "USBD_MAX_POWER_MA=500", "ARDUINO=10810", "ARDUINO_ARCH_RP2040", "F_CPU=133000000L", "BOARD_NAME=\"pico\"", "CFG_TUSB_MCU=OPT_MCU_RP2040", "USB_VID=0x2e8a", "USB_PID=0x000a", "USB_MANUFACTURER=\"Raspberry Pi\"", "USB_PRODUCT=\"Pico\"", "SERIALUSB_PID=0x000a", "" ], "cStandard": "c17", "cppStandard": "c++17", "compilerPath": "/Users/sstaub/.platformio/packages/toolchain-rp2040-earlephilhower/bin/arm-none-eabi-gcc", "compilerArgs": [ "-march=armv6-m", "-mcpu=cortex-m0plus", "-mthumb", "-iprefix/Users/sstaub/.platformio/packages/framework-arduinopico", "@/Users/sstaub/.platformio/packages/framework-arduinopico/lib/platform_inc.txt", "" ] } ], "version": 4 }

maxgerhardt commented 2 years ago

Hm looks good. I cannot reproduce this in Windows. grafik Rebuilding the Intellisense and e.g., Ctrl or Cmd-Clicking on the #include <Arduino.h> line does not get rid of the error? All includes are found here. Restart VSCode maybe?

sstaub commented 2 years ago

Intellisense rebuild doesn't help. I have seen the same problem some times ago on the MS Arduino plugin for VSC and also at the Arduino IDE 2.0

maxgerhardt commented 2 years ago

Can you, just as a test, add

build_flags = -I/Users/sstaub/.platformio/packages/framework-arduinopico/pico-sdk/src/rp2_common

to the platformio.ini and rebuild Intellisense again? Are all errors gone or does it show more nested errors..

sstaub commented 2 years ago

Also that is what I get:

maxgerhardt commented 2 years ago

Windows has no problem here. grafik Only other thing I can test is on Linux since I don't have a Mac.

sstaub commented 2 years ago

No changes.

sstaub commented 2 years ago

I will look deeper inside tomorrow .

maxgerhardt commented 2 years ago

Compilation works because the include folders specified in https://github.com/earlephilhower/arduino-pico/blob/master/lib/platform_inc.txt are included in compilation with https://github.com/earlephilhower/arduino-pico/blob/578d3d2a768bff6b7d978c3eb271381c4a0fdc72/tools/platformio-build.py#L45-L46, but this does not show up in .vscode/c_cpp_properties.json since the builder script does not export it in CPPPATH. The problem is, if I do it there, then it's double in there with -iprefix. If I remove -iprefix, I deviate from the Arduino compilation.

Somehow at least on Windows, VSCode is still smart enough to find the include within framework-arduinopico, on Mac not (?). Weird.

maxgerhardt commented 2 years ago

This is reproducable on Linux too. I will push a fix in the builder script for this.

maxgerhardt commented 2 years ago

This will be fixed by https://github.com/earlephilhower/arduino-pico/pull/615 (not an issue platform-raspberrypi or this PR).

@sstaub if you want to test it out, please replace the contents of /Users/sstaub/.platformio/packages/framework-arduinopico/tools/platformio-build.py with the new version and rebuild intellisense again.

Edit: This was merged, so the framework-arduinopico update should get pulled by pio platform update https://github.com/maxgerhardt/platform-raspberrypi.git

flaviut commented 2 years ago

Tested on Arch Linux, both the uf2 & picoprobe upload work great! Nice work!

I didn't test debugging.

sstaub commented 2 years ago

The errors and warnings passed away. Now I have to check uploading. Thanks

maxgerhardt commented 2 years ago

@sstaub It seems the Intellisense issue is caused by Microsoft, not PlatformIO's builder script: See https://github.com/platformio/builder-framework-arduino-core-mbed/issues/4. Downgrading the C/C++ by Microsoft extension solved the error. Microsoft's stuff is buggy as hell.

Edit: This bug was fixed by Microsoft, update the C/C++ extension to the latest possible version.

earlephilhower commented 2 years ago

@maxgerhardt I have added automatic Platform.IO publishing of core releases and uploaded the 2.1.1 version (under review). If it works, then the Platform.IO release will happen automatically on a Arduino package release. If not, please let me know what I broke and I'll try and correct it!

maxgerhardt commented 2 years ago

https://registry.platformio.org/tools/earlephilhower/framework-arduinopico/versions is visible now (thanks @earlephilhower!), I will work on getting a PR in for https://github.com/earlephilhower/arduino-pico/issues/612 and do more testing (possible Adafruit TinyUSB integration faults, recheck race conditions again), then I can reference the next stable version.

valeros commented 2 years ago

Hi @maxgerhardt ! Many thanks for an awesome PR. Please check my comments in the review. Does something make sense?

maxgerhardt commented 2 years ago

I'm waiting for https://github.com/earlephilhower/arduino-pico/pull/633 to be merged, then I'll merge https://github.com/maxgerhardt/platform-raspberrypi/pull/8 which should resolve the first round of review comments.

Edit: Done.

valeros commented 2 years ago

Thanks for the updates. I've just added minor comments. After that we should be ready to merge.

maxgerhardt commented 2 years ago

Second round of PR comments are worked in.

valeros commented 2 years ago

Thanks for the fixes. LGTM, one last thing is a proper package with the framework. Should we wait for a stable release with the latest changes to the build script?

maxgerhardt commented 2 years ago

Yes, also we're currently investigating some issue with Multicore / thread safety things (https://github.com/earlephilhower/arduino-pico/issues/614) and TinyUSB (https://github.com/earlephilhower/arduino-pico/issues/630, I need to check the latter myself and the fix for the first thing might require a change to the builder script and toolchain package -- I would wait those two out, then reference the next stable framework and possibly toolchain version in the platform.json.

This should hopefully be done within the next 7 days maximum.

earlephilhower commented 2 years ago

The multicore stuff looks to be fixed and I've just published the new toolchain and framework package.

earlephilhower commented 2 years ago

@maxgerhardt are we good to go on this? The core seems solid multicore (at least there are no known bugs :crossed_fingers: ) and the TinyUSB stuff seems to be upstream related and more of a "works, but is/always was awkward" than "is busted."

Only thing you might check, is that if you hardcoded any version numbers of packages. There was a new toolchain built for the multicore fixes and there have been a couple framework updates (latest published today) from when this was initially proposed...

maxgerhardt commented 2 years ago

@earlephilhower I'd say when the Mac OS ARM64 toolchains are uploaded (or rather, reuploaded with just a different manifest) as discussed in https://github.com/earlephilhower/arduino-pico/issues/661#issuecomment-1168447394 then a new 2.0.2 should be released so that the PlatformIO fix https://github.com/earlephilhower/arduino-pico/pull/658 is integrated. Then I can reference fixed versions for both toolchain + framework and do a final test, then this would be good to merge.

earlephilhower commented 2 years ago

@maxgerhardt I've done a new core code release and had to do a full new upload, but Mac is now showing x64 and arm64. I think we're good to go:

maxgerhardt commented 2 years ago

I've updated the package.json to use the latest stable 2.2.2 release and the latest toolchain, the latter by fixed version (5.100300.220629). That is because as long as the underlying GCC version is 10.3.0, it will be using 5.100300.x, but still breaking changes can be made between two x versions but for a specific core version, the toolchain version should be exactly fixed.

@valeros I have no further things to add to this PR :)

(Edit: corrected 2.0.2 in comment to 2.2.2, commit has correct content but wrong wrong title)

earlephilhower commented 2 years ago

Awesome, thanks! (BTW, it's 2.2.2, not 2.0.2. I double checked and you're good).

Apologies for my ignorance, but at this point if I do a new core release (which happens relatively frequently since there are quite a few new boards in the pipe for the RP2040), do I need to do any PR here or will this take the latest core version? (i.e. only if I need to rev the toolchain do I need to do a PR)?

maxgerhardt commented 2 years ago

For the update process multiple scenarios are possible. Basically after this PR the core version and toolchain version and boards would be fixed, and no publishing of packages from your side would auto-update the available platforms here.

For updating the core or toolchain with a new version (after it was uplaoded to the registry), a PR would have to be made that updates these versions in the platform.json. For updating the boards, a PR would have to be made that copies the boards from json to boards.

However both of these actions can also be done by PlatformIO staff directly in this repo without outside PRs. (Though triggering it by PR would be faster in my opinion and experience). Maybe @valeros can propose something for future updates.

maxgerhardt commented 2 years ago

It's slightly concerning though that after the registry upload, older versions of the package are gone? Like in https://registry.platformio.org/tools/earlephilhower/framework-arduinopico/versions and https://registry.platformio.org/tools/earlephilhower/toolchain-rp2040-earlephilhower/versions, I could swear there were previous versions before that.

We'll want to make sure that when CI publishes a package the old ones don't get nuked o_o

Older versions which are now gone were e.g. referenced in

https://github.com/esphome/esphome/pull/3284/files#diff-4446afd728a4f34cbcddc306a9cb6be845d1a61c216076a295683bcc9c106724R155-R157

earlephilhower commented 2 years ago

We'll want to make sure that when CI publishes a package the old ones don't get nuked o_o

All I did was pio package publish <file>. I didn't unpublish anything. I assumed the PIO guys did it, since this was a pre-release/merge set?

maxgerhardt commented 2 years ago

Possibly. Hm, @ivankravets could you have a look at logs on what happened to earlephilhower/framework-arduinopico@1.20101.0 on how / why it was deleted?

ivankravets commented 2 years ago

I assumed the PIO guys did it, since this was a pre-release/merge set?

Yes, we set 1 version per package. @maxgerhardt, please check your e-mail to discuss this PR.

maxgerhardt commented 2 years ago

Thanks to @earlephilhower's amazing work (❤️), we now have Raspberry Pi Pico W support in its first version with a WiFi library in PlatformIO. See arduino-wifi-scan example and use board = rpipicow :)

(Example was also added to the CI here.)

yngndrw commented 2 years ago

I'm trying to upload a basic blink program using the wiznet_5500_evb_pico board within this PR and I keep getting an upload error. The upload works fine from the Arduino IDE. (Windows)

AVAILABLE: cmsis-dap, jlink, picoprobe, picotool, raspberrypi-swd
CURRENT: upload_protocol = picotool
BeforeUpload(["upload"], [".pio\build\wiznet_5500_evb_pico\firmware.elf"])
Auto-detected: COM4
Forcing reset using 1200bps open/close on port COM4
"C:\Users\Andrew\.platformio\packages\tool-rp2040tools\rp2040load" -v -D .pio\build\wiznet_5500_evb_pico\firmware.elf
rp2040load 1.0.1 - compiled with go1.15.8
.....................
*** [upload] Error 1

If I copy the file .pio\build\wiznet_5500_evb_pico\firmware.uf2 to the drive which opens it works fine. It also works fine if I manually run the following command instead: "C:\Users\Andrew\.platformio\packages\tool-rp2040tools\rp2040load" -v -D .pio\build\wiznet_5500_evb_pico\firmware.uf2

It appears to be trying to upload the incorrect file but to be honest I'm not that well up on these Picos, PlatformIO and the upload process in general. Am I doing something wrong or is this a bug for this board?

maxgerhardt commented 2 years ago

It could be the Arduino IDE uses a different port? What happens when you plug the board in with BOOTSEL pressed so that the flash drive appears? Does PIO then fail upload too? Did you load WinUSB drivers for the "RP2 Boot2 (Interface 1)" device using Zadig? (Device only appears when Pico is in bootloader mode).

Note that for the very first flash, you may need to manually put to the .uf2 file on the boot drive, for subsequent uploads the COM reset should work properly then.

yngndrw commented 2 years ago

It's using the same port - At first it couldn't detect it so I set the port manually but later the automatic detection also worked, I wasn't sure what changed for that to work but it might have been when I manually uploaded the uf2 file as you say. I've tried both the COM port and the drive letter.

I've tried with and without using BOOTSEL and have loaded the WinUSB drivers.

I've tried with more verbose logging but it doesn't show anything more that the "Error 1" line.

maxgerhardt commented 2 years ago

In the Arduino IDE, does it use rp2040load 1.0.1 - compiled with go1.15.8 too at this version? The

.....................

usually appears when the rp2040load can't find the Pico in bootloader mode or the correct drivers aren't installed so the program can't access it. When you open the Windows device manager, do you see the Pico ejecting and reappearing in bootloader mode?

yngndrw commented 2 years ago

The Arduino IDE doesn't appear to use rp2040load at all, here's the end of the logs from Arduino IDE:

Sketch uses 48972 bytes (2%) of program storage space. Maximum is 2093056 bytes.
Global variables use 7264 bytes (2%) of dynamic memory, leaving 254880 bytes for local variables. Maximum is 262144 bytes.
C:\Users\Andrew\AppData\Local\Arduino15\packages\rp2040\tools\pqt-python3\1.0.1-base-3a57aed/python3 -I C:\Users\Andrew\AppData\Local\Arduino15\packages\rp2040\hardware\rp2040\2.3.2/tools/uf2conv.py --serial COM4 --family RP2040 --deploy c:\Users\Andrew\Programming\Arduino\.build\GearDisplay/tower-controller-test.ino.uf2 
Resetting COM4
Converting to uf2, output size: 104448, start address: 0x2000
Flashing I: (RPI-RP2)
Wrote 104448 bytes to I:/NEW.UF2

Using PlatformIO, it does indeed show up within device manager: (And a few seconds later, the volume opens in Windows Explorer - About 1/3 of the way through the ...)

It then continues waiting before eventually giving up:

<lambda>(["upload"], [".pio\build\wiznet_5500_evb_pico\firmware.elf"])
AVAILABLE: cmsis-dap, jlink, picoprobe, picotool, raspberrypi-swd
CURRENT: upload_protocol = picotool
BeforeUpload(["upload"], [".pio\build\wiznet_5500_evb_pico\firmware.elf"])
Auto-detected: COM4
Forcing reset using 1200bps open/close on port COM4
"C:\Users\Andrew\.platformio\packages\tool-rp2040tools\rp2040load" -v -D .pio\build\wiznet_5500_evb_pico\firmware.elf
rp2040load 1.0.1 - compiled with go1.15.8
.....................
*** [upload] Error 1
=================================================================================== [FAILED] Took 15.42 seconds ===================================================================================

maxgerhardt commented 2 years ago

But it shows up as libusb-win32 device, if WinUSB drivers were loaded it should show up under the USB device category (differently named). Can you double check to load WinUSB and not libusb-win32 drivers for the interface 1 device?

And yes I see, the Arduino IDE does a reset into bootloader (through the serial reset) and then copies the file onto the harddrive -- not through rp2040load which uses the boot USB interface. However, rp2040load should in general work still.

yngndrw commented 2 years ago

Apologies, I completely misread the driver when I looked earlier - I've uninstalled the libusb-win32 driver and re-installed the correct WinUSB driver and it now works correctly.

Thank you very much!

cstrahan commented 2 years ago

@maxgerhardt

Does this support logging via Real-Time Transfer (RTT)?

For a point of comparison, I have another project written in Rust where I use probe-run to program my Pico as well as view debug output via RTT. I have one Pico I use as the debugger (running DapperMime, specifically this file), which connects to my other target Pico via the SWD pins. This lets me program, debug and view logs with just the three SWD pins, and I only need one command line invocation of probe-run to kick it all off. Also, because I power the target Pico through the debugger Pico (by tying the two VSYS together, ditto for GND), I only need the one USB cable to the debugger.

Presently, this is how I have my new Arduino Pico project setup in PIO:

[env:pico]
platform = https://github.com/maxgerhardt/platform-raspberrypi.git
board = pico
framework = arduino
board_build.core = earlephilhower
board_build.filesystem_size = 0m
upload_protocol = cmsis-dap
debug_tool = cmsis-dap

I can successfully program my Pico just as I described above, but when I click PlatformIO: Serial Monitor in VSCode that gives me this window:

 *  Executing task in folder arduino_pico_tests: platformio device monitor 

--- Terminal on /dev/ttyACM1 | 9600 8-N-1
--- Available filters and text transformations: colorize, debug, default, direct, hexlify, log2file, nocontrol, printable, send_on_enter, time
--- More details at https://bit.ly/pio-monitor-filters
--- Quit: Ctrl+C | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H

I'm curious if there's any option provided by this work (or maybe its integral to PIO, and orthogonal to this PR -- in which case my apologies for asking here) that would allow me to view RTT output? (And I suppose that would need to use something like koendv/RTT Stream to do the printing, instead of the usual Serial.println)

cstrahan commented 2 years ago

Using the koendv/RTT Stream library, I've figured out how I can use pyocd to view RTT from another terminal:

$ pyocd rtt --target rp2040 --probe 'cmsisdap:0'
0000244 I Target type is rp2040 [board]
0000265 I DP IDR = 0x0bc12477 (v2 MINDP rev0) [dap]
0000279 I AHB-AP#0 IDR = 0x04770031 (AHB-AP var3 rev0) [ap]
0000299 I AHB-AP#0 Class 0x1 ROM table #0 @ 0xe00ff000 (designer=43b:Arm part=4c0) [rom_table]
0000305 I [0]<e000e000:SCS v6-M class=14 designer=43b:Arm part=008> [rom_table]
0000308 I [1]<e0001000:DWT v6-M class=14 designer=43b:Arm part=00a> [rom_table]
0000311 I [2]<e0002000:BPU v6-M class=14 designer=43b:Arm part=00b> [rom_table]
0000317 I CPU core #0 is Cortex-M0+ r0p1 [cortex_m]
0000322 I 2 hardware watchpoints [dwt]
0000325 I 4 hardware breakpoints, 0 literal comparators [fpb]
0000328 I RTT control block search range [0x20000000, 0x040000] [rtt_cmd]
0000491 I _SEGGER_RTT @ 0x20000e38 with 3 aUp and 3 aDown [rtt_cmd]
hello world!
hello world!
hello world!
hello world!
hello world!
hello world!
hello world!
hello world!
hello world!
hello world!
hello world!
hello world!

Though it would be really great if I could have this integrated into PIO: if I have pyocd printing RTT in another terminal, PIO upload fails from VSCode:

Configuring upload protocol...
AVAILABLE: cmsis-dap, jlink, picoprobe, picotool, raspberrypi-swd
CURRENT: upload_protocol = cmsis-dap
Uploading .pio/build/pico/firmware.elf
Open On-Chip Debugger 0.10.0+dev-ge3428fadb-dirty (2022-07-14-14:57)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
debug_level: 1

adapter speed: 1000 kHz

Error: unable to find CMSIS-DAP device
Error: No Valid JTAG Interface Configured.
*** [upload] Error 255
================================== [FAILED] Took 0.37 seconds ==================================

So I have to stop one to start the other.

maxgerhardt commented 2 years ago

if I have pyocd printing RTT in another terminal, PIO upload fails from VSCode:

Yes, one program claims the CMSIS-DAP exclusively.

Does this support logging via Real-Time Transfer (RTT)?

Making RTT logs show up in the PlatformIO device monitor would be more suited as a general request for the core: https://github.com/platformio/platformio-core/issues.

However, I think it's pretty trivial to add tool-pyocd (already existing) to platform-raspberrypi and add a custom platform target (just like "Upload Filesystem" is) that executes the pyocd rtt --target rp2040 --probe 'cmsisdap:0' command. I'll think about adding it in.

earlephilhower commented 2 years ago

Signed OTA has been added to the latest release, so if we want to support that as well I think the script here needs to be updated to do the crypto-signing, in some sort of pre- and post-build process. Plain OTA should work fine as long as a .BIN file is output from the standard processes.

platformio / platform-raspberrypi

Arduino-Pico (Earlephilhower) support, PicoProbe Debugging #36