Arduino_Core_STM32 WIP: Allow uploading using open-ocd-supported programmers

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:

Select the board as normal
Select any upload method without a custom bootloader (to get the flash start address correct)
Select the programmer from the "Tools -> Programmer" menu (note that this currently shows all programmers which is not really useful, this should be fixed in Arduino).
Select sketch -> Upload using programmer

Mar 20 '20 17:03 matthijskooijman

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... 🙄

Mar 21 '20 15:03 fpistm

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 https://github.com/arduino/OpenOCD-build-script/issues/2), so I changed this PR to just select stlink.cfg (without a version) and it will autodetect the version, which is even nicer :-)

I've planned to provide the xpack-dev-tools/openocd-xpack/releases with the core.

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 ~/.arduino15/packages/arduino/tools/openocd.

Mar 22 '20 11:03 matthijskooijman

W00ps, misclick :-)

FYI, I submitted a PR (https://github.com/arduino/Arduino/pull/9900) for the Arduino IDE to make it not show all programmers, only the relevant ones.

Mar 22 '20 12:03 matthijskooijman

The OpenOCD build script used by Arduino is now also made up-to-date, see https://github.com/arduino/OpenOCD-build-script/issues/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).

Mar 23 '20 09:03 matthijskooijman

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

Mar 23 '20 09:03 fpistm

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.

Mar 26 '20 13:03 matthijskooijman

Thanks @matthijskooijman managing bootloader upload was also in my huge todo list. Seems promising. For the unified shell scripts naming you can use the master of the tools repo: https://github.com/stm32duino/Arduino_Tools

Mar 26 '20 13:03 fpistm