This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CCS/TM4C1290NCZAD: DFU update via dfuprog.exe

Part Number: TM4C1290NCZAD

Tool/software: Code Composer Studio

I am attempting to add dfu capability to an existing USB serial application on a custom TM4C1290NCZAD board. I wish this to use the ROM based USB boot loader, and have the capability to have the firmware update triggered from dfuprog.exe from Windows 10 command line.

I think I have setup my custom device as a DFU and USB Serial composite device (I used boot_demo_usb example for dk-tm4c129x as a starting point, and have serial USB rather than mouse HID). Although there is no Product Id for this in usb-ids.h, currently I am using USB_PID_COMP_HID_DFU, as I believe this is what the boot_demo_usb.inf file looks for. 

My composite device strings. (do these matter as far as functionality is concerned?).

My Serial CDC device initialization (this works).

This is my DFU structure declaration.

Here is the actual initialization of the composite device.

This is my Composite device. Both Serial and DFU together inside the g_comp_entries_s.

On my device manager (Windows 10) I see my device come up twice. Once as the serial device (which works). And the DFU part comes up in "Other devices" and displays my product string I setup in the composite device descriptor. Why is there no section for DFU devices?

When using "dfuprog.exe -e" from command line, I see the following error. 

I have installed the included boot_demo_usb.inf file, and the install completes successfully. The following is the windows_drivers directory of my TivaWare installation, that I retrieved from http://www.ti.com/tool/SW-TM4C. I believe them to be the latest drivers. I am not prompted by windows when I plug in my DFU device.

I have pointed to this location manually when clicking on my "unknown device" and going to update drivers from local folders. When I do this Windows shows the following.

Any help that you could provide would be greatly appreciated.

  • note: by latest drivers I mean latest .inf files, as well as the accompanying folders with DLLs.

  • Additional can someone confirm that the ROM based USB boot loader, in the absence of any code in Flash memory, switch to DFU for an update? If it does not do this, then how would I enable this feature?

  • Hello Alexander,

    I hadn't tried to use the DFU programming with the ROM USB boot loader before so I am testing out a few things to explain how it works, I'll update later in the day.

  • Thanks for all your assistance Ralph.

  • Hello Alexander,

    So I think the core issue here is just trying to get the DFU Composite device setup right, I am putting together a code example on my LaunchPad both to give you and also so I can go through the process and understand the steps in order to walk you through what needs to be done. I expect when that is done, the dfuprog.exe portion should be straightforward.

  • Yes and no. I have used the example boot_demo_usb which is a composite DFU.

    It appears to be completely functional on the firmware side. 

    Windows just is unable to find the driver or setup the DFU properly for some reason. Also dfuprog.exe has a similar issue. I would be willing to bet, however, that it is not the firmware setup that is the issue, but I could be wrong. I think it is either a driver issue or .inf file issue, this may or may not be caused by firmware problems.

    Again thanks so much for all your help Ralph.

  • Hello Alexander,

    That's what I meant by setup properly - make Windows recognize it.

    You are right that it looks to be an issue regarding the drivers / .inf files, and there lies a problem I am not really sure how to solve.

    The drivers provided with TivaWare for the composite DFU is specifically in conjunction with a HID device. But in this case, you are doing a composite CDC + DFU.

    I think what is happening is Windows is expecting another device to arrive along with the DFU device due to the composite setup, and it also sees a waiting CDC device. It goes ahead and enumerates the CDC device as a standalone, because the descriptors do not indicate the CDC device is part of the composite. So then when it goes to enumerate the DFU device, it's trying to do as a composite but doesn't see the second device as the CDC has already been taken care of, so the enumeration does not complete. It looks like they picked HID because it's simple and doesn't need anything advanced to work from a driver standpoint, as there are no HID drivers we deliver, while CDC needs some specific configurations.

    I've been trying to figure out what needs to changed, but frankly I've never made or edited any windows drivers, and I am at a loss as to what would need to be changed to allow for a CDC + DFU setup...

  • To add, I went ahead and did some testing with the DK board to see how it enumerates, and it shows up as a combo device which is not what the current drivers would support for a CDC + DFU interface.

    That said, I may have found a route to help, it looks like TI-RTOS did an example of serial DFU for TM4C, let me see what I can re-use.

  • I have some idea myself. The descriptors (USB_PID_COMP_SERIAL etc. (see in usb-ids.h)) for it appear to just be arbitrary numbers (PID) that the .inf file looks for. Due to this I expected that keeping the same descriptors as the example would still work.

  • Hello Alexander,

    I have an idea that may work really quickly, give it a try, I'm gonna continue to work on it on my end too as I am only about 50% sure this will work.

    1) Download the zip file from here: http://processors.wiki.ti.com/index.php/TI-RTOS_USB_DFU#Part_6_-_USB_Composite_Device

    2) Go to [Folder Location]\ek_tm4c1294xl_usb_serial_dfu\ccs\usbserialdfu\Windows

    3) Grab the two .inf files and drop them into your TivaWare list.

    4) *IMPORTANT* Change the PID from USB_PID_COMP_HID_DFU to 0x0102.

    With the new PID, that should, in theory, allow those two new Windows drivers properly enumerate the device... that is, as long as everything else about the setup mimics how the RTOS version was configured.

  • Alright. Progress. I have a new error. The .inf are not signed, but it least it found them. Now I just have to sign them (note, don't know how to do this...).

  • Hi Alexander,

    That's a huge step forward.

    The signed driver issue unfortunately is a bit of an obstacle as I have checked and even for the TivaWare drivers we'd hit the same problem. The drivers as they are now won't enumerate a CDC+DFU, but if I modify them then the signature will be invalid and we'd be right back to the same point you are right now.

    I have a query open to the RTOS team to see if they happened to have signed the drivers at some point. I don't expect that to be the case, but can't hurt asking.

    Unfortunately, we don't have the ability to just sign a driver on our end, so if that is the final obstacle then I'm afraid I've hit my limit as to what I can offer for support. Though I hope what I've provided so far as gotten you close to your end goal.

  • By the way, depending on your PC security settings, you should be able to turn off the check for signed drivers. Google can explain how. I can't because my PC has software that prevents this, but if you can, then you could validate it works.

  • Alright. I think it is good now. dfuprog.exe

    Device Manager.

    I will still have to figure out how .inf files work to make my own eventually. And I need to test the actual firmware upgrade capability.

    But thank you so much Ralph for getting me here!

  • Awesome! Glad I was able to guide you through this, I was a little worried for a bit there with the drivers :)

    By the way, now that you went through this, were there any inaccurate parts of the steps in Section 2.11.1 Using the DFU Device Class? Or were you able to follow that step by step to get here once the drivers were fixed?

  • Well... Actually that is what an earlier post that I have on this site was all about. Referring to the USB Library User guide right?

    The section in question says to use bl_config.h and APP_START_Address, citing boot_demo_usb as an example. Except that, the example does not do this, as it has no FLASH boot loader (only ROM). (Other portions of that section are helpful though)

    I have a forum post for it here. https://e2e.ti.com/support/microcontrollers/other/f/908/t/816698

    Also, I am unfortunately not out of the woods yet. Everything appears to be working but when I use the dfuprog.exe command to switch it into a programming mode, it does not work.

    The device should be visible as a DFU mode (rather than run-time mode) device. Maybe I do not have the .inf file for that type? 

    Either way it does not show up on device manager at all after this.

  • Hello Alexander,

    Yeah I recorded your messages there, but since we got so much further along, I wanted to be sure those were the only issues.

    Can you post device manager screenshots

    1) After flashing the board and before DFU is triggered

    2) After the -m command

    3) After the -e command

    I had stopped my porting efforts on my end, but I could resume that tomorrow if needed. Though since you did some leg work, could you share the usb structs file you put together? Be sure to edit out any of your own info if so of course. I was in the midst of getting all of that sorted out when I stumbled into the driver issue, and skipping that step would get my attempt running much quicker.

  • I have a few theories of what I am doing wrong first.

    a) do I have to be powering it from a different source than the USB port I am using for a DFU update?

    b) if I am using USBDDFUUpdateBegin(); to trigger the update, do I need to change the SVCall handler in the starup_css.c file?

    Here are the snips you requested.

    1) After flashing the board and before DFU is triggered

    2) After the -m command

    3) After the -e command (should be no change here)

    As far as sending my usb structs file, if you mean the file with my composite device initialization, most of it is depicted in my initial pictures of this question (only change was 0x102 for tUSBDCompositeDevice PID). It has a lot of extra tx/rx stuff in it that I could gut out, but may take a bit. Lets run down my two possible errors from above first. I you would :). Then I can see about editing my structs file and sending it.

  • I switched my call to svc handler to ROM_UpdateUSB(0);. This is the result now.

    1) Before

    2) After

    I think that I need a different .inf file for DFU update mode (that the USB lib sets up for me now, so I don't think I have control over PID now right?). So I would think that it would be a default driver, perhaps boot_usb.inf, when I point to that folder for a driver update Windows gives me this.

    Note: windows also tells me in the properties for that device, that it used usb.inf.

    I think I am stuck now. Got any ideas?

  • So I changed from using usb library USBDDFUUpdateBegin() with a change to use ROM_UpdateUSB(0) rather than a SVC handler call.

    I switched to using my own custom function that came from the boot_demo_usb example, and I think it is working now. (it is mostly the same as USBDDFUUpdateBegin(), there are some differences).

    Unfortunately I cannot yet test it. Ill let you know when I do. But it seems to be okay now.

  • Hello Alexander, 

    If you are looking to use the ROM boot loader, than that is what you should do. I have never tried using USBDDFUUpdateBegin to invoke the ROM boot loader, so I'm not sure exactly how to even do that. ROM_UpdateUSB is definitely what I would recommend using for the ROM boot loader, that is the proper way to go about it.

  • Hey Ralph Jacobi,

    So, I think it is setup now correctly. I can now restart it in update mode, and I can send down the updated firmware. Unfortunately it does not restart in my new firmware. After a manual reset it is still not in my firmware (I can tell because the composite COMs do not come back). It is also not in the boot loader in ROM, as that DFU port does not come back either.

    It may be because I used the dfuwrap.exe from the RTOS example that you sent me, in order to change my .bin to a .dfu. 

    Sincerely, Alex.

  • After I put it in update mode I check to see if it is there (now it is, yay). Then I try to push the firmware to the device. Appears to be successful, however, if it is successful then I should see the Composite USB devices appear on device Manager. (see below for results)

    Note: I have now tried a Tiva C dfuwrap.exe instead (same result).

  • Okay. complete success. 

    I just used a .bin, instead of worrying about making it a .dfu first. 

  • Okay I was going to suggest that but had wanted to test it myself first and hadn't gotten a chance to do so, thanks for the report back and patience through this journey!

  • Hey Ralph, |

    Thanks again for all your help. Just wondering if you ever heard back from RTOS, as the signed driver would still be useful to me if they had it.

  • Hello Alexander,

    It doesn't appear that they got the drivers signed on their end yet from the feedback I got.