RTOS/EK-TM4C1294XL: USB DFU Composite Device

Windows 10.  Just OTG USB connected to PC. 

COM11 last event listed:

Driver Management concluded the process to install driver usbser.inf_amd64_d49c1a9bc63fc04e\usbser.inf for Device Instance ID USB\VID_1CBE&PID_0102&MI_00\6&3382D9DC&0&0000 with the following status: 0x0.

Tivaware Device Firmware Upgrade last event listed:

Driver Management concluded the process to install driver usb_serial_dfu.inf_amd64_20ee184920bd438f\usb_serial_dfu.inf for Device Instance ID USB\VID_1CBE&PID_0102&MI_02\6&3382D9DC&0&0002 with the following status: 0x0.

Is this a hypothetical question to plan out firmware development, or do you mean literally there is a device in a customers hands and they want to upgrade?

The DFU and push button application seems viable. I owned a router that required the reset button pressed during power on for special functionality.

I updated the driver for the USB to the version in the link and it ran the install but when I go to device mgr it shows a microsoft driver.  If I try to update it says best drivers already installed.

Only the OTG USB of the board is connected to the PC.  I tried a reboot of the board but no joy.

Hello Sam,

Which example firmware do you have loaded onto the board specifically? Also can you try using LMFlash programmer and see what the results are?

Using the TivaWare boot_serial example w/ LMFlash Programmer I can see the DFU option without issue.

I am not familiar with the dfuprog.exe operations so I would need to look into that next week if needed, but most of our customers to my knowledge use LMFlash for this.

Looking through examples, I don't see one which is for a composite device, can you share the example I should load onto my LaunchPad that would be for a composite device?

I imported the example using the resource explorer from:

TI-RTOS for TivaC->Tiva C series->Tiva TM4C1294NCPNT->EK-TM4C1294XL Evaluation Kit->Driver Examples->TI Driver Examples->USB Examples->USB->Serial Device

And then followed the directions in the document titled : USB Serial Device Firmware Upgrade (DFU) dated Jan 12, 2016 that I downloaded from the TI Wiki 

http://processors.wiki.ti.com/index.php/TI-RTOS_USB_DFU 

There are two versions, one that requires pressing the USR1 pushbutton to enter DFU mode and the other via a command.

The first version works and even works with LM Flash Programmer 1613.  The command version does not work either by command prompt or LM Flash Programmer.

Is there another example that I should try?

Okay, so I set the new flash settings on the first example but NOT the second.

I will let you know if that fixes it.

Thanks

The instructions suggest the driver may not be included. The tutorial instructs the user to install two drivers from a normal TivaWare install directory. This last driver install is the only one included with the project download. It might be a one time special driver.

I will try the patch.

Update: the driver did not install with a different error message "Windows could not find drivers for your device."

project map file:

OUTPUT FILE NAME:   <usbserialdfu.out>

ENTRY POINT SYMBOL: "_c_int00"  address: 000099e9

MEMORY CONFIGURATION

        name            origin    length      used     unused   attr    fill

----------------------  --------  ---------  --------  --------  ----  --------

 FLASH                 00004000   000fc000  00009bd0  000f2430  R  X

 SRAM                  20000000   00040000  00002048  0003dfb8  RW X

Device Mgr

Still no joy.

Sam

Sam,

I'm just coming up to speed on this thread. I would like to confirm the fundamental issue. From what I've read, it seems that you are working on Windows 10. In this environment, when you use the command dfuprog to transition the Tiva board from runtime mode into DFU mode, it fails to do so. The device is in some unknown state and fails to enumerate properly. Have I got this correct?

In addition, Ralph has indicated that the composite device support in the USB stack is currently non-functional on Windows 10 due to some changes in USB enumeration. Bummer.

Finally, are you looking for the composite feature because the device does not have buttons?

Thanks,
~Ramsey

Yes, Windoz 10.

Was trying to avoid having to add a button to the device but not a deal breaker.

The button version works well so I might work around that one.

Thanks,

Sam

I turn off signed drivers and I see the same error as Sam after giving the dfuprog -m command.

The vendor ID appears to have changed.

Sam,

To pursue this a little further. Building a composite device is not the only option.

I don't know what your device does when its connected to a PC, but I assume it would be communicating with some software entity. If you have control over this, then your software entity could send a command to the device (using its primary interface) to enter DFU mode. The device would reboot and be ready for upgrade.

The composite device example was just an illustration of how to enter DFU mode using a separate interface. But if you have control of the primary interface, then maybe you could use that interface for both runtime mode and DFU control.

~Ramsey

Sam,

In case you want to pursue the single interface approach, I'm attaching a file which contains a function for switching from USB run-time mode to USB DFU mode.

DFU_sample_code.zip

There are several steps required to switch from USB run-time mode to USB DFU mode. This includes terminating the current USB interface and detaching from the USB bus. Followed by a few hardware details regarding interrupts, resetting the USB controller, and PLL frequency programming. Last step is to connect to the USB bus again and re-enumerate as a USB DFU device. The sample code performs these steps with the help of the ROM code on the TM4C1294 device.

When your application decides to switch from run-time mode to DFU mode, shutdown application services as needed, then call the DFU_renumerate() function.

~Ramsey

Thanks.  Sorry for the long gap in reply, was out of town on personal matters.

Sounds like a lot of juggling and steps that could go wrong in the field.

Being that the hardware (pushbutton) solution seems reliable, I think I might just build a hardware slution such as an on board circuit that is activated from the touch screen to put the board in DFU mode.

Sam

Sam,

Understood. Using a button is probably a wise decision. Best of luck.

~Ramsey