EK-TM4C123GXL: How to generate a file from CSS to load it using USB DFU via LM Flash Programmer

MAURICIO VIDAL

Part Number: EK-TM4C123GXL
Other Parts Discussed in Thread: UNIFLASH, EK-TM4C1294XL

Hi everyone:

I think I’m making a mistake when generating the file to be used to program an EK-TM4C123GXL using LM Flash Programmer with USB DFU. For now, I don’t intend to make any custom implementation, neither on the uC nor in the host computer. I mean, I’ll stick to the vanilla functions of the ROM TivaWare, use the default USB id, based on project0, etc.

I guess what I'm finally need to resolve is: What should I set for the CCS Project to generate a file that can be used to program an EK-TM4C123GXL using the LM Flash Programmer via USB DFU?

This is what I have tried:

If I program the EK directly from CSS, the Bootloader on the uC runs and LM Flash Programmer is able to see it and make it available to be programmed again when selecting Manual configuration and USB DFU as the interface. This should mean that my uC app and the host Windows machine and its drivers are okay.

However, at this point, when loading the .bin (Taken from the output folder of the CSS Project) just leaves the uC not working and subsequently not being able to be programmed again via its Bootloader.

I think the problem is not the .bin. If I restore the uC (Programing it again directly from CSS) and then using LM Flash Programmer selecting the Profile: TM4C123G LaunchPad and the same .bin, the device works. But loading again the very same .bin from LM Flash Programmer but using DFU, leaves the device out of work.

I suspect that the LM Flash Programmer may need a different file (other than the .bin) that tells it something about the memory locations. By the way, I’m relaying on ROM_UpdateUSB(0) and I have checked that the .cmd file of the Project matches the TivaWare 2.2.0.295 version, and has this addresses:

#define APP_BASE 0x00000000
#define RAM_BASE 0x20000000

That makes me think that I have not to change the address field that has the value 0 on the LM Flash Programmer, which seems the only thing variable there.

Any help, would be greatly appreciated.

11 months ago

0 Charles Tsai 11 months ago

TI__Guru**** 184986 points

MAURICIO VIDAL said:
I mean, I’ll stick to the vanilla functions of the ROM TivaWare, use the default USB id, based on project0, etc.

MAURICIO VIDAL said:
However, at this point, when loading the .bin (Taken from the output folder of the CSS Project) just leaves the uC not working and subsequently not being able to be programmed again via its Bootloader.

The way the ROM bootloader works after a reset is that it will first look for a valid application indicated by a non-F's values at address 0x0 and 0x4. These two locations contain the stack pointer and the reset vector. After you load the project0 example the first time, whether you load it via JTAG or DFU, the address at 0x0 and 0x4 becomes valid. The next time after a reset cycle, the ROM bootloader finds that there is already a valid application (the project0 example), it will just jump to the application and execute. The project0 example is a simple example that only toggles the LED. There is no code in the example to jump back to the ROM bootloader unless you modify the example. After an application is already present on the flash, the only way to overwrite it is through JTAG using CCS/LM flash programmer/Uniflash. Or you can erase the flash again. By erasing flash, the address location 0x0 and 0x4 will contain all 0xF values. After a reset, the ROM bootloader will detect that there is not an valid application and hence will run the ROM DFU bootloader to reload an application firmware again, be it the project0 example or any other program.

If you want the application to jump back to the ROM bootloader by calling ROM_UpdateUSB, refer to the C:\ti\TivaWare_C_Series-2.2.0.295\examples\boards\ek-tm4c1294xl\boot_demo_usb example. This is an example for TM4C129 and you can reference and migrate to TM4C123. Read the example description extremely carefully so that you don't load the firmware to the ICDI MCU on the board. There are two MCUs on the board. One is the target MCU and another is enumerating as a ICDI debug probe. Both will show up as DFU capable devices. If you load the example firmware to the ICDI MCU, you will render ICDI bricked and it is not recoverable.

//! <h1>Boot Loader USB Demo (boot_demo_usb)</h1>
//!
//! This example application is used in conjunction with the USB boot loader in
//! ROM and turns the development board into a composite device supporting a
//! mouse via the Human Interface Device class and also publishing runtime
//! Device Firmware Upgrade (DFU) capability. Pressing USR_SW1 will trigger
//! the USB mouse interface to move the cursor in a square pattern once. This
//! is a basic example of how HID reports are sent to the USB host in order to
//! demonstrate controlling the mouse pointer on the host system.
//!
//! Since the device also publishes a DFU interface, host software such as the
//! dfuprog tool can determine that the device is capable of receiving software
//! updates over USB. The runtime DFU protocol allows such tools to signal the
//! device to switch into DFU mode and prepare to receive a new software image.
//!
//! Runtime DFU functionality requires only that the device listen for a
//! particular request (DETACH) from the host and, when this is received,
//! transfer control to the USB boot loader via the normal means to re-enumerate
//! as a pure DFU device capable of uploading and downloading firmware images.
//!
//! Windows device drivers for both the runtime and DFU mode of operation can
//! be found in <tt>C:/TI/TivaWare_C_Series-x.x/windows_drivers</tt> assuming
//! you installed TivaWare in the default directory.
//!
//! To illustrate runtime DFU capability, use the <tt>dfuprog</tt> tool which
//! is part of the Tiva Windows USB Examples package (SW-USB-win-xxxx.msi)
//! Assuming this package is installed in the default location, the
//! <tt>dfuprog</tt> executable can be found in the
//! <tt>C:/Program Files/Texas Instruments/Tiva/usb_examples</tt> or
//! <tt>C:/Program Files (x86)/Texas Instruments/Tiva/usb_examples</tt>
//! directory.
//!
//! With the device connected to your PC and the device driver installed, enter
//! the following command to enumerate DFU devices:
//!
//! <tt>dfuprog -e</tt>
//!
//! This will list all DFU-capable devices found and you should see that you
//! have one or two devices available which are in ``Runtime'' mode.
//!
//! *** IMPORTANT - PLEASE READ ***
//! If you see two devices, it is strongly recommended that you disconnect
//! ICDI debug port from the PC, and change the POWER_SELECT jumper (JP1)
//! from 'ICDI' to 'OTG' in order to power the LaunchPad from the USB
//! OTG port. The reason for this is that the ICDI chip on the board is
//! a DFU-capable TM4C129x device, and if not careful, the firmware on the
//! ICDI chip could be accidently erased which can not restored easily.
//! As a result, debug capabilities would be lost!
//! *** IMPORTANT - PLEASE READ ***
//!
//! If IDCI debug port is disconnected from your PC, you should see only one
//! device from above command, and its index should be 0, and should be named
//! as ``Mouse with Device Firmware Upgrade''.
//! If for any reason you need to keep the ICDI port connected, the above
//! command should show two devices. The second device is probably named as
//! ``In-Circuit Debug interface'', and we need to be careful not to update
//! the firmware on that device. So please take careful note of the index for
//! the device ``Mouse with Device Firmware Upgrade'', it could be 0 or 1, we
//! will need this index number for the following command.
//! Entering the following command will switch this device into DFU mode and
//! leave it ready to receive a new firmware image:
//!
//! <tt>dfuprog -i index -m</tt>
//!
//! After entering this command, you should notice that the device disconnects
//! from the USB bus and reconnects again. Running ``<tt>dfuprog -e</tt>'' a
//! second time will show that the device is now in DFU mode and ready to
//! receive downloads. At this point, either LM Flash Programmer or dfuprog
//! may be used to send a new application binary to the device.

0 MAURICIO VIDAL 11 months ago in reply to Charles Tsai

Intellectual 260 points

Hi Charles,

Thank you for your prompt response.

It seems I did not express myself correctly when explaining my setup. When I mentioned the Project0, what I should have said instead, is that my CSS project is based on that template. The actual code on it that my app is running has only one task: call the Bootloader, and apparently it works.

Taking its .bin and programing it on the EK's uC (But only via ICDI) works: The uC after the reset enumerates on the Windows computer to allow a new program to be loaded via USB DFU. But it I take the very same .bin (that was working) and load it now using the USB DFU interface (instead the ICDI), the uC fails to start.

That’s why I’m suspecting that the .bin is not correct file to be used for USB DFU, or that I'm missing extra info for the LM Flash Programmer to load the program.

EDIT: Here it is the code I'm using over the Project0 template:

#include <stdbool.h>
#include <stdint.h>
#include "inc/hw_gpio.h"
#include "inc/hw_ints.h"
#include "inc/hw_memmap.h"
#include "inc/hw_sysctl.h"
#include "inc/hw_types.h"
#include "inc/hw_nvic.h"
#include "driverlib/debug.h"
#include "driverlib/gpio.h"
#include "driverlib/interrupt.h"
#include "driverlib/sysctl.h"
#include "driverlib/pin_map.h"
#include "driverlib/timer.h"
#include "driverlib/uart.h"
#include "driverlib/ssi.h"
#include "driverlib/rom.h"


void JumpToBootLoader(void)
{

	// Configure the required pins for USB operation.
	ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOD);
	ROM_GPIOPinTypeUSBAnalog(GPIO_PORTD_BASE, GPIO_PIN_5 | GPIO_PIN_4);

	// Disable all interrupts.
	ROM_IntMasterDisable();

	// We must make sure we turn off SysTick and its interrupt before entering
	// the boot loader!
	ROM_SysTickIntDisable();
	ROM_SysTickDisable();

	// 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;
	HWREG(NVIC_DIS2) = 0xffffffff;
	HWREG(NVIC_DIS3) = 0xffffffff;
	HWREG(NVIC_DIS4) = 0xffffffff;

	// Enable and reset the USB peripheral.
	ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_USB0);
	ROM_SysCtlPeripheralReset(SYSCTL_PERIPH_USB0);
	ROM_SysCtlUSBPLLEnable();

	while(!ROM_SysCtlPeripheralReady(SYSCTL_PERIPH_USB0))
	{
	}

	// Re-enable interrupts at the NVIC level.
	ROM_IntMasterEnable();

	ROM_UpdateUSB(0);
}

void main(void) {

	ROM_FPULazyStackingEnable();

	// Set the system clock to run from the PLL at 80MHz.
	SysCtlClockSet(SYSCTL_SYSDIV_2_5 | SYSCTL_USE_PLL | SYSCTL_OSC_INT | SYSCTL_XTAL_16MHZ);

	// Wait a bit
	SysCtlDelay(3);

	// Transfer control to the boot loader.
	JumpToBootLoader();

}

0 Charles Tsai 11 months ago in reply to MAURICIO VIDAL

TI__Guru**** 184986 points

Hi,

You cannot just modify the project0 example to simply call ROM_UpdateUSB(). Your code does not present itself as a USB DFU or as any USB device to the host. Your code is doing nothing but setting up the clock and immediately jumps to the ROM bootloader without the USB first initialized and enumerated correctly with the host. This will not work. Same analogy, you cannot just call ROM_UpdateEMAC or ROM_UpdateUART and hoping that it will start bootloading from Ethernet or UART interface without first having these modules initialized. Refer to the boot_demo_usb example.

0 MAURICIO VIDAL 11 months ago in reply to Charles Tsai

Intellectual 260 points

Dear Charles,

I already have solved my issue. The whole problem was that lousy USB connector used on the EK-TM4C123GXL. The clue was a sudden chime of the Windows machine when it recognized the EK in DFU mode after an unintentional touch of the USB cable. Every other test on different EKs with the exact code I presented on the post before worked flawlessly.

But I want to express my frustration with your previous responses. I really doubted about what I had posted and even in my knowledge of the devices I have used for years when I read what you stated in your last post.

On the code I presented, the custom function JumpToBootLoader takes care of the system and USB preparation. I guess you missed that, and just jumped to conclusions.

Anyway, thanks.

Arm-based microcontrollers

Arm-based microcontrollers forum

EK-TM4C123GXL: How to generate a file from CSS to load it using USB DFU via LM Flash Programmer