[scons] Add Black Magic Probe Programming method (again)

[strongly-typed]

This was added back in 2016 in 7f0d2ef, but disappeared when migrated to modm.

This shall solve #148 Add "programming capabilities/scons/Black Magic Probe"

• Tested with STM32F1 blue pill
• Add documentation to module.md
• Add example in documentation
• Add debugging method like scons openocd-debug / scons bmp-debug.
  Postponed to a rework of the upload feature of modm.

[salkinium]

This was added back in 2016 in 7f0d2ef, but disappeared when migrated to modm.

The issue is fundamentally that the SCons tools in xpcc didn't really deal with the user's programmer/debugger stack very well and I removed it in modm since there still wasn't a unified concept with how to deal with accessing targets.

I would like to see a concept for retargeting the existing semantics of the CLI onto the user's specific targets:

• scons program transparently uses either OpenOCD or BMP or DFU or STLink
• scons gdb transparently runs both GDB and programmer

This needs to work WITHOUT hardcoding information as an lbuild option, since the black_magic_probe.port is obviously going to be different for other users and OSes (the :build:avrdude* options are also questionable here).

Ideally I would like to see an automated guess as to what programmer to use, probably using pyUSB to check the connected programmers and before choosing one.
Alternatively we need to find a different solution that doesn't hardcode the BMP port in lbuild.

Add documentation @salkinium: where to put?

Add it to module.md and use a better option description like the rest.

PS: Something with the CI is wrong, it seems to show an incomplete output from your own CI fork.

[salkinium]

Alternatively to the automated detection, I'd also be ok with using arguments to specify the programmer and port:

scons program type=bmp  # automatically choose port for BMP
scons program type=bmp port=/dev/usbserial.foobar  # use specific BMP
scons program type=openocd usbid=serial  # in case your have multiple openocd programmers connected
scons program  # use OpenOCD
scons program  # in future: automatically choose programmer and port

This would just default type to openocd for now and can implement the automatic programmer choice later. This would be my preferred solution for now.
(Maybe type is too generic? I want something short to type.)

[strongly-typed]

openocd != ST-Link, but so far this is the only combination we use. openocd offers many other debug adapters.

arm-none-eabi-gdb + Black Magic Probe is the other combination I am using.

Also to be considered:

• Deal with serial and CAN bootloaders
  • at least the ones which are preprogrammed to STM devices
  • optionally, all 'official' bootloader protocols like app note AVR109 (which is commonly used by Arduino I think)

I would like to see a concept for retargeting the existing semantics of the CLI onto the user's specific targets:

• scons program transparently uses either OpenOCD or BMP or DFU or STLink
• scons gdb transparently runs both GDB and programmer

I am in favour of

• scons upload (or even flash if target is flash.)
• scons debug

And debug can also be something else, not tied to the gdb tui forever. Saw some nice web-based tool.

How to proceed?

[salkinium]

• scons upload (or even flash if target is flash.)
• scons debug
  And debug can also be something else, not tied to the gdb tui forever. Saw some nice web-based tool.

Ok, agreed. I never like scons program too much myself, scons upload is much better.

Deal with serial and CAN bootloaders

Yes, good point! The intergrated STM32 bootloaders would be very nice to have.
There is also the programming of external Flash modules, for example the F469 Discovery board has an external QuadSPI Flash connected, which OpenOCD is still reviewing a patch for (since 2016!): http://openocd.zylin.com/#/c/4321/. There's also a generic bit-bang version: http://openocd.zylin.com/#/c/4760/.

I would very much prefer to delegate this to other projects (like OpenOCD or BMP) though, instead of duplicating this effort somehow in modm.

How to proceed?

A "proper" solution requires larger changes that need to be planned and prototyped. I'm opening a new issue to keep track of this discussion.

For this PR I would the BMP functionality as the scons bmp port=/dev/usbserial format.
I wouldn't add the scons gdb functionality since it probably requires too many changes for now (like setting the correct port in gbdinit.in using the tools).

[strongly-typed]

For this PR I would the BMP functionality as the scons bmp port=/dev/usbserial format.

What is the best way to read the command line parameter in the script? Is there any example that uses command line parameters already?

[salkinium]

See the user guide:
https://scons.org/doc/3.0.4/HTML/scons-user.html#sect-command-line-variables

[strongly-typed]

tools/build_script_generator/scons/resources/SConscript.in
14:profile = ARGUMENTS.get("profile", "release")

Yeah ;-)

[salkinium]

Thanks!