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.

  • Resolved


I have a Tiva C TM4C123GXL Launchpad EK and I'm trying to figure out how to us the DFU.  I'm able to flash the device via CCS in debug mode and using the LM Flash Programmer but I'd like to be able to see how it will work on my board and we will not be using the JTAG.  I thought I could simply flash the boot_usb program and after reset see the device on the Device USB port and not just the DEBUG USB port using the dfuprog application.  On our board we plan to use the USB to load user programs and not necessarily have the JTAG support.  

I can use the Bulk example to run the echo program through the Device USB port.  Is it possible to also program the flash from this port?  If so what am I missing?  I want to be able to run the dfuprog app to access this USB port.  What does this require?

  • I think I may have figured it out.  I read:

    "The boot loader is used as an initial program loader (when the Flash memory is empty) as well as

    an application-initiated firmware upgrade mechanism (by calling back to the boot loader). "

    I simply erased flash and it ran.  How do I "call back to the boot loader"?  Is it possible to accidentally clobber the boat loader is it truly in ROM? I'm afraid to try flashing through this port and bricking my EK.

  • In reply to Tim Whipple:

    I've been unable to get into DFU mode from an application.  I can only reach it by erasing flash at this point.

    I'm starting with boot_demo1 and modifying it from what I can piece together from various forum posts but I'm still missing something.  

    From the ROM guide I found;

    enable the main PLL and configure it as the system clock,
    enable the USB PLL,
    enable the USB controller,
    enable the USB D+ and D- pins on the microcontroller.
    If the main application is already acting as a USB device,
    the application must remove the device from the bus by calling the DriverLib function
    ROM_USBDevDisconnect() prior to entering the boot loader.  I don't believe this is the case but may be in the future.  As of now I simply try to jump to BOOT ROM

    I currently have:





    //The code I've used to enable the USB D+ and D- pins has varied and I think may be the key but i can't find the proper initializations steps

    HWREG(NVIC_DIS0) = 0xffffffff;
    HWREG(NVIC_DIS1) = 0xffffffff;

    ROM_UpdateUSB(pui8USBBootROMInfo);   //uint8_t *pui8USBBootROMInfo = NULL;

    Am I missing anything besides the D+/- enable?

    Any ideas what this entails?  I trued the PinMux app but it generates code with defines that don't seem to exist anywhere.  Other attempts have proven just as fruitless.  

  • In reply to Tim Whipple:


    In TivaWare, there is a more in depth example for the DK-TM4C129x called boot_demo_usb that shows how to use the USB boot loader in ROM.  Although this device is different from the EK-TM4C123GXL, the basic concept is still there.

    The ROM Boot Loader "listens" for whatever peripheral you are trying to use.  You must use the PLL for your system clock, turn on the USB PLL and the USB peripheral clock (all of these steps are present in your code).  Enabling the D+/D- pins is done when you initialize the USB.  In most cases, a USB application would be running before switching over to the ROM boot loader.  This is done in the boot_demo_usb example.



  • I intend to make use of the ROM bootloader too. My current thought is as follows.

    I will dedicate one of the otherwise unused GIOP as my to-boot-or-not-to-boot pin. I will also alter the contents of the non-volatile register BOOTCFG. NW is of course cleared. The PORT and PIN fields designate my to-boot-or-not-to-boot pin. POL bit can be either way as desired. NW bit is cleared. KEY, DBG1 and DBG0 are unchanged.

    After that, I can try various Application code. The Application code may have the option to initiate the ROM bootloader. But even if it failed to do so or does not have this option, I can still start ROM bootloader manually.

    Is this scheme okay?

  • In reply to old_cow_yellow:

    I've been able to jump to Boot ROM and execute the DFU functionality using some of your other posts for different but similar boards.  I think one of my hang ups was not realizing I had to use the power switch in the non-debug mode for it to work properly.  I had no idea this would affect the functionality as other functionality seems fine.  In debug mode the code would jump into a fault isr or just seem to get lost. you mentioned I will be using the chip in a mode with the USB already running.  I gather that this requires some different steps to jump to DFU mode in the Boot ROM.   I do plan on the chip acting as a bulk USB device to accept commands and respond.  One such command would be to jump to Boot ROM in the case where a software update to the code is needed.

    I'm unable to find a software project  'DK-TM4C129x - boot_demo_usb' on the ti website.  Is this something that can be found without purchasing that demo board as well?

  • In reply to Tim Whipple:

    I tried using the usb_dev_bulk project to get into DFU mode but no luck.  Like I said before I can load a program that will simply enable the SB and jump to BootROM to enter DFU mode but when I try to do the same in the usb_dev_bulk project it doesn't work.  I simply modified the code to respond to a certain character to switch modes.  WHen this command is received I call:


    and then I simply follow the steps I used in my basic boot project.  What additional steps are needed?  If I can find the 'boot_demo_usb' project will it have more information on the differences?

    My call to USBDBulkTerm(pvBulkDevice); definitely unloads the USB device, as I see it fall from my driver list,  but the following steps that work in another simply project fail to yield the same results and successfully reboot into DFU mode.

  • In reply to Tim Whipple:

    Sorry for the delayed response.


    Yes, this sounds correct.  You just have to make a call to ROM_Update<Peripheral> to call the ROM boot loader from your application.  Otherwise, the ROM boot loader will be called if your Flash memory is empty.  If you have any issues, let me know.


    The boot_demo_usb project can be found in TivaWare.  If you download the full version of TivaWare, it is in the default path C:\ti\TivaWare_C_Series-2.0\examples\boards\dk-tm4c129x\boot_demo_usb.  You do not have to purchase the board to have access to this code, you'll just have to port it over to your LaunchPad.

    If you look at this example, it turns the board into a composite USB device supporting a mouse via HID class.  The device listens for a request from the host (DETACH) and then the reenumerates as a DFU device.  After receiving the DETACH request, the device is detached from the bus (using USBDCDTerm(0)), disables interrupts and processor interrupts, enables and resets the USB peripheral, re-enables interrupts at the NVIC level, then makes a call to the USB boot loader in ROM.  Try working off of this example; I think it will be more clear.



  • In reply to Rebecca Ringhof:

    I always seem to get the USB device being seen as an 'Unknown USB Device' it won't show up as a DFU Device.  It only works using the simple boot_demo1 example I modified.  If I use the usb_dev_bulk and try to follow the DETACH example as a basis to switch to DFU mode it comes back as an unknown usb device.

    This is what I'm trying and shows the modifications I made:

    // Terminate the USB device and take us off the bus.
    USBDBulkTerm(0);     //USBDCDTerm(0);

    // Disable all interrupts.

    // Disable SysTick and its interrupt.

    // Disable all processor interrupts. Instead of disabling them one at a
    // time, a direct write to NVIC is done to disable all peripheral interrupts.
    HWREG(NVIC_DIS0) = 0xffffffff;
    HWREG(NVIC_DIS1) = 0xffffffff;

    // Enable and reset the USB peripheral.

    // Wait for about a second.

    //ROM_SysCtlDelay(ui32SysClock / 3);
    ROM_SysCtlDelay(ROM_SysCtlClockGet() / 3);

    // Re-enable interrupts at the NVIC level.

    // Call the USB boot loader.

  • In reply to Tim Whipple:

    I've tried quite a few variations on this too.  Adding steps I use in the simple example that goes straight to DFU mode but I always get Unknown USB device.  I can't figure out what is missing.   The examples I've found aren't working for me.

  • In reply to Tim Whipple:


    I tried this on my end by modifying the usb_dev_bulk example (.c file attached).  The only difference I can see between your code and my code is that I used USBDCDTerm(0); instead of USBBulkTerm(o);.  I would recommend doing this.  I'm not sure where your code was added as this can also make a difference.  I was able to see my LaunchPad come up as a Stellaris Device Firmware Upgrade device in the Device Manager and was able to reprogram it with a different binary file using dfuprog.exe (instructions on how to use this and where to find it can be found in the readme.txt in the boot_demo_usb project folder for the dk-tm4c129x).  Make sure to program your binary to the board using the ICDI Debug USB port and then switch power to power from the Device USB port on your LaunchPad, as to not confuse the number of DFU devices found.




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.