More flexible firmware upload support for multiple targets and programmers

[salkinium]

scons program should be renamed to scons upload and support a more generic way to upload firmware to the device (preferrably only wrapped by SCons so it can be reused by CMake).

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

Original comment:

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.

[salkinium]

Additionally when having multiple programmers connected, it should be possible to detect which targets are connected and automagically choose the right one for the current context.
So if I have a bunch of Nucleos connected, the script needs to probe all targets IDs (once with cache?) and choose the Nucleo that matches the current :target. Alternatively a mechanism must be provided to select a specific programmer or specific device (using UID, USB port or serial number?).

It would also be nice to automatically select the right serial port for bootloaders, if that is possible.

[rleh]

scons upload or scons download?
Arguments could be found for both terms, so I am strongly in favour of scons program!

[salkinium]

Well, 🤓🤓akschtually🤓🤓 OpenOCD is doing both an upload and a download or the other way around to verify the firmware writing was successful. But joking aside, of course we would alias scons program to a new command if any.

[salkinium]

I think scons upload would be the correct term, since they are user centric as in a webbrowser, where upload means "data going away from the user's machine", and download "data going towards the user's machine". The user's machine here being the USB Host where the user calls SCons. 🤓🤓🤓🤓🤓🤓🤓🤓

[rleh]

I recently worked with EtherCAT devices and there a transfer from the Computer to a device on the bus (slave) is called download. Transferring data from the connected device to the computer is called upload.

Therefore I would prefer not to use the term upload anyway, but a more unmistakable term like program or flash.

[salkinium]

Ok, no directional commands then. What we have is:

• scons/make program: transfers the firmware using some mechanism onto the device, could also be into RAM.
• scons/make debug: Some way to launch an integrated debug environment. We have GDB TUI, which is better than nothing, but gbdgui integration would be super nice.
• scons/make log: A way to automatically find the right serial and possibly perform additional off-device formatting and filtering. For example, when using ITM as a serial output, some unprintable character are sent (currently ignored).

[se-bi]

scons program: transfers the firmware using some mechanism onto the device, could also be into RAM.

I just wanted to ask: Is their a scenario where flash would not be suitable?

When and why is loading into RAM used?

But, I am also struggling with program.

[salkinium]

When and why is loading into RAM used?

For example when you want to execute a bunch of unittests without wearing down the flash too much. In most devices there is enough RAM to fit both code and data. (this needs linkerscript support, which we currently don't have). Also EEPROMs and other non-flash based storage exist ;-P

But, I am also struggling with program.

Yes, I, the programmer, don't like the programming my program via a USB programmer thing. But it's not super important for me, it's just a name at the end of the day.

[salkinium]

I've refactored the SCons tooling to extract the common code into a stand-alone Python library that makes it easier to implement more complex features (like auto-detecting of programmer) without having to worry (too much) about how to integrate that into the build system. I resurrected a all programming methods and integrated them fully with debugging via GDB tui or gdbgui. Currently implemented:

• scons/make program: via OpenOCD (by default)

• scons program-remote: via OpenOCD already running somewhere

• scons/make program-bmp: via Black Magic Probe

• scons/make debug ui={tui|web}: GDB via OpenOCD (by default)

• scons debug-remote ui={tui|web}: GDB via OpenOCD somewhere else

• scons/make debug-bmp ui={tui|web}: GDB via Black Magic Probe

• scons/make debug-coredump ui={tui|web}: GDB via CrashCatcher

[se-bi]

Is there plan to address to boards by there type, e.g. nucleo_xy, discovery_xy or whatever one is using

or only via the iSerial which is offered by the programming device?

Like building some kind of memory / cache either in the modm clone or somewhere in $HOME,
where a mapping of iSerial to board type is stored,
whenever the board was programed the first time as the only one connected.

(Maybe also refuses to program, if there are multiple boards and no mapping)

[salkinium]

Is there plan

Yes. Somewhere in my head there is a plan. I'm almost certain of it! 😜

The broad idea is something like scons/make program port={usb-port} serial={hex}? It's not trivial to detect and categorize connected devices, so I didn't want overload the PR with even more functionality.

[salkinium]

We should use the libusb1 Python library to detect what kind of programmer is available, then choose the best one.

[salkinium]

We should be looking at pyOCD as a replacement for OpenOCD.