Custom bootloader and application sharing USB CDC device?

[Antypas.Peter]

I'm building an appliance that has both a custom bootloader for serial-based firmware update as well as an application that interfaces to a PC using serial.

The processor is STM32L432KBU6 (128K flash). I don't think the budget permits the cost of the KCU6 (256K flash).

Originally, I designed it using a CP2104 USB to UART bridge with the ST part operating a UART only. As an experiment in BOM reduction, I tried using the STM32 USB CDC device, and I got it to work. There is a caveat, however:

Every time the system resets, the USB device resets as well and has to go through re-initialization (which means re-enumeration), thus breaking the connection with the PC app.

Rather than resetting the processor to pass control to a bootloader for firmware download, I considered using a flasher app that runs from some alternate address (Flash or SDRAM), so that control can be passed to it via the usual jump mechanism. But how would this process "take over" the CDC device without a hiccup?

I need to clarify here that the firmware image is going to be so large that I can't fit 2 of them side by side on Flash, so the bootloader/flasher will have to do a live download / erase / write.

Thanks in advance,

Peter

[waclawek.jan]

The usual approach is that the bootloader sits at the lowest sectors, and is written well enough that it never changes (trying to keep it minimalistic helps to get it right). Here, it might've contain the whole USB+CDC stack, handling data at the application level based on a single flag steering between bootloader/application.

JW

[Antypas.Peter]

OK, so if the bootloader initializes the USB device, is there a way for the application to "take over" the interface without re-initializing it?

[Pavel A.]

> is there a way for the application to "take over" the interface without re-initializing it?

IMHO this is a wrong approach and you should do just the opposite: make the PC app responsive to USB disconnects. This is good to have even without bootloader and update scenario.

Windows has well known ways to detect removal and re-connect (though complicated).

-- pa

[waclawek.jan]

> OK, so if the bootloader initializes the USB device, is there a way for the application to "take over" the interface without re-initializing it?

Why not? Look at the application only as an extension of the bootloader's functionality, which works conditionally. Have a flag in RAM, cleared at reset, and set when the bootloader jumps to application (after having checked its integrity etc.). At the application level of the USB stack (implemented in the bootloader area), steer the code based on state of this flag, to the handler in the bootloader, or to the handler in the application.

Don't expect this to be something you generate through a couple of clicks in CubeMX, though.

JW