WIP: Allow uploading using open-ocd-supported programmers #1002
Conversation
|
Thanks @matthijskooijman I've planned to provide the https://github.com/xpack-dev-tools/openocd-xpack/releases/ with the core. I do not known well the mechanism for external programmers. I have to investigate this also... 🙄 |
matthijskooijman
force-pushed
the
programmers
branch
from
225a22d
to
d4965cc
Compare
|
I just tested ST-link, worked as expected. It did give me a warning that selecting a particular ST-link version was deprecated (apparently the openocd version supplied by Arduino was newer than the 0.10 installed by apt which I used to see valid options, not sure what verfsion the ship exactly, see arduino/OpenOCD-build-script#2), so I changed this PR to just select
Good plan, that project seems to do releases from openocd git (since there hasn't been an official release since 0.10.0 a long time ago). For this PR, I've just used some openocd version supplied by Arduino, so if you're going to test this, make sure that the version number in platform.txt matches the version number in |
|
W00ps, misclick :-) FYI, I submitted a PR (arduino/Arduino#9900) for the Arduino IDE to make it not show all programmers, only the relevant ones. |
|
The OpenOCD build script used by Arduino is now also made up-to-date, see arduino/OpenOCD-build-script#2. It turns out they are also shipping OpenOCD versions that build from OpenOCD git master, so it might be feasible to just use their version instead of rolling your own (though I'm not sure how this works wrt installing it, since the IDE normally puts tools under the vendor directory, so it might still end up being installed twice). |
|
Yes that would be easier to use the one from Arduino. When I've checked it was outdated that's why I think about the xpack one which seems to be more up to date |
This adds the compiled binary version of all variants, directly from the upstream zip file.
This adds the "bootloader_only_binaries" directory from commit df68980 (Updated 'Congratulations' sketch in the combined bootloader...) from https://github.com/rogerclarkmelbourne/STM32duino-bootloader. This intentionally does *not* use the binaries that use the welcome sketch, since that sketch disables the debug port (since it is built with Roger Clark's Arduino_STM32 core, which disables the debug port unconditionally currently).
This reverts commit 84e4091. Temporarily reverted, because the tool package change needed for this does not seem to be published yet.
This allows uploading the HID bootloader and the stm32duino bootloader (aka maple bootloader 2.0) to the bluepill and blackpill boards (other boards could also be added, but a bootloader version must be explicitly selected for each board). The bootloader is chosen based on the "Upload method" selected and uploaded with the selected programmer using openocd. This uses the non-fastboot bootloader, since the current bootloader autoreset for this bootloader just does a normal reset. If that would be modified to set the right RTC register with a magic value to stop the fastboot in the bootloader (pretty much exactly like the hid bootloader), we could instead use the fastboot version.
|
I pushed a few more commits to also allow uploading a bootloader using the Arduino IDE (hid bootloader and stm32duino aka maple 2.0, only for blue/black pill boards so far), which works nicely. These might need some additional work to include an empty sketch with the bootloader (so the first upload through the bootloader works right away), or maybe to actually do a flash erase (so the bootloader won't find a valid sketch and keeps spinning), but we'll have to see. Also, just realized I have not looked at the bootloader licenses to check for any conditions (notices) on redistribution. |
|
Thanks @matthijskooijman |
This is just a proof of concept so far, but it allows using external programmers such as ST-LINK or the Atmel JTAGICE3 or Atmel ICE through the IDE "Upload using programmer" option.
I needed uploading through my Atmel JTAGICE3, which was my only SWD programmer available (though I just also got an STLINK I have not tested yet). The JTAGICE3 is a generic CMSIS-DAP SWD programmer, so it also supports STM32.
It did not make sense to add this programmer as another upload method for all boards, since that would be a lot of work, and the IDE already has a mechanism for external programmers: Upload using programmer.
This implements support for uploads using openocd-supported external programmers to (for now) just the PILL_F103XX variant boards. Each variant still needs a openocd config file (alternatively, the openocd target name could be specified in boards.txt as well).
Most of this configuration can later probably be reused for step-by-step debugging support using openocd (which is being added to arduino-cli right now).
I've tested this using JTAGICE3 on a bluepill. I've also added entries for STLINK, but have not tested them yet (yet to unpack my new vSTLINK programmer).
To use this: