USB CDC (Virtual COM) and DFU (Device Firmware Upgrade)

etan · ‎2011-10-06

Posted on October 07, 2011 at 01:22

Hi, i m using stm32 cortext m3. Is it normal to have CDC (virtual com port) combine with FDU to become a composite USB device? Is there any example on this? Thanks.

This is so that a PC application can perform not only firmware upgrade but also other communication/operations with uC. The PC application will make sure that uC is in the right mode before performing firmware upgrade.

stforum.tormod9 · ‎2011-10-09

Posted on October 09, 2011 at 11:11

I think you mean DFU, not FDU. Yes, it is normal for a device to expose a DFU interface in addition to their ''normal'' interfaces. The DFU interface is in this case in ''run-time'' mode. When a DFU_DETACH request is sent to the DFU interface, the device will enter DFU mode, and then only the DFU interface will be exposed, and is ready to receive the firmware update through DFU_DNLOAD requests.

etan · ‎2011-10-09

Posted on October 10, 2011 at 07:30

So sorry, typo. It should be DFU (Device Firmware Upgrade). Thanks for pointing out and the reply.

Is there any stm32 example that implemented CDC and DFU class together?

stforum.tormod9 · ‎2011-10-10

Posted on October 10, 2011 at 10:13

ST's own examples (from the USB FS Device Library) do not use standard DFU, and the device is booting directly into DFU mode (if e.g. a special button is pressed).

But take a look at the Maple project, they have tried the combined serial + DFU device approach, the problem seems to be the driver handling in MS Windows:

http://leaflabs.com/docs/bootloader.html

etan · ‎2011-10-10

Posted on October 10, 2011 at 17:18

Thanks again for the info. It seems that IAD is the solution to windows driver. Any idea on how to quickly modify ST's examples of FDU and CDC to run both function at the same time?

stforum.tormod9 · ‎2011-10-11

Posted on October 11, 2011 at 22:05

The ST DFU example (using DfuSe, not the normal DFU protocol) is always in DFU mode. I would not try to combine it with another interface. But if you are fine with a solution where only one of the interfaces boots up depending on some hardware switch, you can use the examples as-is.

If you want a standard DFU device that will switch from run-time to DFU mode (and allow combined interfaces) you should look at the Maple code instead.

etan · ‎2011-10-12

Posted on October 13, 2011 at 05:13

Thank you.

>>If you want a standard DFU device that will switch from run-time to DFU mode (and allow combined interfaces) you should look at the Maple code instead.

Yes, I think this is what I want. I prefer to modify using st example because there is already a PC host software (Dfuse Demonstration) codes, which I can modify to add other controls for uC through CDC. This would save time. At any time, I would like to be able to upload/download firmware or control other features implemented in uC immediately, rather than reset and go into DFU mode wait loop. Besides, the CDC and DFU example is already working on the uC that I am using. So, things would be quicker if I use these examples instead of Maple? What do you think? I am new to this.

>>ST's own examples (from the USB FS Device Library) do not use standard DFU

The example on desktop uses STDFU.DLL and it seems that it does not support IAD. Do you have any info? I implemented IAD in uC. The PC software (DfuSeDemo.exe) STDFU_GetDFUDescriptor( ) return STDFUPRT_NOERROR but the contents are empty. As a result, DfuSeDemo.exe could not proceed into DFU. Does this means I cannot use DfuSeDemo.exe even if IAD is successfully implemented? STDFU_GetDFUDescriptor( ) is in STDFU.DLL and codes are not available.

Thanks again.

stforum.tormod9 · ‎2011-10-30

Posted on October 30, 2011 at 10:32

Yes, if you want the DFU down/uploading to be possible all the time, you might as well use the DfuSe firmware code. You should be able to combine the example DFU and CDC interfaces, but it might not be straight-forward and you will have to understand USB and the USB firmware code well. For instance, you will have to merge both into one Data_Setup function in usb_prop.c and dispatch according to which interface is being addressed. Would be interesting to see if you can make it. Is this an open-source project?

For your DfuSeDemo.exe issues, I have no idea. I am using an open-source firmware loader.