DFU - Windows host, USB transport and proprietary protocol. A way out

[Gabriele]

Hi,
I have to develop a new nRF5340/Zephyr/MCUBoot-based device that communicates with a Windows application via USB.
The Windows application already manages other legacy products. For them all a proprietary protocol is already in place for downloading a new firmware image (DFU).
What is the simpler strategy to manage this on the device side ?
In the past I've used the SMP server plus MCUmgr (https://docs.zephyrproject.org/2.6.0/samples/subsys/mgmt/mcumgr/smp_svr/README.html), but in that case I worked with a serial transport, and did not have a proprietary protocol to abide by.

Thank You

[Gabriele]

Hello Hung,
I apologize for the late reply.
I know how to manage DFU when the firmware image is downloaded from UART or BLE.
However in this case I need to use the USB interface.

In addition to that the firmware image cannot be stored in flash as it is received form the USB interface. Some processing is required. 

[Hung Bui]

Hi Gabriele, 
I'm afraid that you will need to look into the SMP_SVR example and develop your own firmware to receive the image via USB. 

But I'm not sure I understand you on why "image cannot be stored in flash as it is received form the USB interface." ? Could you elaborate ? Do you mean that the image is encrypted and you need to decrypt it before storing it ?

[Gabriele]

Hi Hung,

The DFU is instigated by a legacy PC SW. This SW uses a proprietary encapsulation of firmware records before transmitting them to the device

[Hung Bui]

Thanks for the info. But it's still a little bit vague to me. So how do you supposed to handle the firmware ? How should it be handled and "unwrapped" for storing ? 

[Gabriele]

I don't know at this moment. Firstly I have to consider all existing supports to DFU via USB, and then see if they are easily patchable