Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WIP: Allow uploading using open-ocd-supported programmers #1002

Draft
wants to merge 5 commits into
base: main
Choose a base branch
from

Conversation

matthijskooijman
Copy link
Contributor

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

@fpistm
Copy link
Member

fpistm commented Mar 21, 2020

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
Copy link
Contributor Author

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

@matthijskooijman
Copy link
Contributor Author

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.

@matthijskooijman
Copy link
Contributor Author

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

@fpistm
Copy link
Member

fpistm commented Mar 23, 2020

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.
@matthijskooijman
Copy link
Contributor Author

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.

@fpistm
Copy link
Member

fpistm commented Mar 26, 2020

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants