TM4C1290NCZAD: DFU ROM bootloader

mskjons said:

In spmu301e.pdf it is said that "the ROM bootloader starts execution by scanning the supported communication interfaces until it receives a valid command to download firmware through a specific interface."

Hi,

  Yes, if the flash is erased, the device will enter ROM bootloader and the USB device port will enumerate as a DFU device. Below is what I see on a LaunchPad. Please try it on a LaunchPad first. The USB device port on the LaunchPad will enumerate as Stellaris Device Firmware Upgrade. 

1. Fully erase the flash

2. Connect USB cable to the USB 'debug' port. When this done, you will see Stellaris ICDI DFU. This is expected because there is a on-board ICDI debug probe.

3. Connect USB cable to the USB 'device' port. When this done, you will see Stellaris Device Firmware Upgrade. It is ready to download your application firmware through this USB port. You can use either LM flash programmer or dfuprog.exe to download your firmware. 

One note of caution, be extremely careful if you are using a LaunchPad to download your firmware. As I showed, there will be two detected DFU devices. You must not by mistake choose ICDI DFU to download your firmware. If you did, you would by mistake program your firmware to the ICDI chip and render ICDI no longer enumerate as a ICDI debug probe. This step is irreversible. 

Thank you for your reply. As I tried to state in my first post, I have absolutely no problems with the ROM bootloader on the eval card, and it shows up whenever I erase the flash, or jump to the bootloader from application code. I can program this usindg dfuprog.exe or dfu-util without issues, and I do not mess with the flash on the ICDI.

My issue is with our custom HW, which does not show up as a DFU device when it is blank.

When I program the device with JTAG, my custom application USB interface enumerates and functions as expected, and when i call ROM_UpdateUSB from the application, the device comes up as a DFU device and I program it in the same way as I can with the evaluation card.

My question is thus, what is the difference between the calling the ROM_UpdateUSB function and when a blank device is scanning the supported cummunication interfaces? As one approach works and the other does not, there seems to be some kind of requirement for the bootloader to enter to DFU mode, which I haven't found any documentation on.

Hi,

mskjons said:

My issue is with our custom HW, which does not show up as a DFU device when it is blank.

With the flash erased, the device will boot up and enter the ROM bootloader and scan for the supported communication interfaces. The question here is if you have other communication interfaces that happened to receive a valid command. Can you do an experiment that make sure no other comm ports are connected other than the USB?

Do you have another board that you can try? Do you see the same problem on all of your custom boards or just one?

Thank you. I have tried several boards, and none show up as a DFU device before I have programmed an application calling the ROM_UpdateUSB function, which makes them all enumerate as DFU. I have also made sure to not have the JTAG connected when testing blank devices.

As for other communication interfaces finding a valid command, I dont think that should be possible, unless I have misunderstood which pins each peripheral uses:

UART0: PA0 and PA1 are unconnected
I2C0: PB2 and PB3 are unconnected
SSI0: PA2, PA3, PA4 and PA5 are routed out to a pinheader, but nothing is connected to this.

Ok,

  That is very weird to me. I have not come across a problem like this in the past. I'm curious about the RBIAS pin you have on your custom board? Are you using Ethernet? I wonder if the below errata has something to do with your issue.