OpenBootloader for STM32L4+ via SPI with Embedded Linux Host (CubeProgrammer/OpenOCD)

[MFolk.1]

There are several good options for implementing an MCU bootloader from an embedded Linux host. Unfortunately, I have hardware that is already in production and therefore I am not able to implement any of the industry standard and simple ICP (In-Circuit Programming) methods for a bootloader. I need to use an IAP approach (In-Application Programming).

Here is my hardware situation. I have an Xilinx Ultrascale+ embedded linux device that we are able to update firmware to out in the field. This system also has a slave MCU (STM32L4S9AII6) that interfaces via SPI. I have a few spare GPIOs also connected between them. I need to be able to program the MCU from the Linux device to make it field programmable with the rest of the system. Unfortunately, despite all the interface options to the MCU's built in ROM bootloader, none of them are wired such that I can take advantage of that so I have no choice but to load my own custom bootloader into the MCU.

I know that ST has OpenBootloader which I have spent my morning researching, but with this approach I have several concerns that I need resolved. I am short on time and I need to make sure I move forward with the best possible design choice to get this up and running.

Here are my concerns:

1. It doesn't seem as though ST has an OpenBootloader project specific for the STM32L4S9AII9 or even the STM32L4+ series. If I am to use OpenBootloader on this MCU, what is my path of least resistance. From following the OpenBootloader readme and corresponding videos and other documentation such as AN2606, it seems my best bet is to start a new project, configure peripherals specific for this MCU, and then copy the application source code from another OpenBootloader project (STM32H573... is the closest I've found) as applicable. I don't like this option but it seems the best I have. Is there a better way? Surely someone else out there has solved this problem before for the STM32L4+ series.

2. Even if I get the OpenBootloader application up and running and tested with the ST-LINK debugger and CubeProgrammer application, I still need to figure out how to best drive this from the embedded Linux host. CubeProgrammer seems to only work with the ST-LINK debugger if I plan to do this over the SPI interface. Perhaps I am wrong about this and then maybe it is possible to install the CubeProgrammer utility on the Linux host and program the MCU via a script using CLI commands. I have spent some time over the past few days experimenting with OpenOCD in hopes I could utilize that, but I'm not sure if that can be easily configured in a way that will be compatible with the OpenBootloader application via the SPI interface. It seems your CubeProgrammer is probably based on the OpenOCD platform so maybe this is the way to go. In any case, I don't have time to learn what won't work the hard way.

Any suggestions will be greatly appreciated. 

Thank you,

Marshall