• State TI Thinks Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 30 subscribers
  • Views 167 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

TM4C1290NCZAD: DFU ROM bootloader

mskjons
Prodigy 50 points
Part Number: TM4C1290NCZAD
Other Parts Discussed in Thread: EK-TM4C1294XL

Are there any specific requirements for the DFU ROM bootloader on this Tiva?

On the Ek-TM4C1294XL eval card, it automatically enters the bootloader after erasing the device, but on custom HW, nothing shows up on the USB on a device with erased flash.

The USB interface itself works as expected after loading an application with JTAG, and the ROM bootloader also works as expected if we enter it from the application by calling ROM_UpdateUSB.

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."

What is the difference between calling ROM_UpdateUSB and when the device is scanning the supported cummunication interfaces?

What can be the reason the DFU bootloader is invoked on a erased device?

  • 0
    TI__Guru**** 183066 points
    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. 

  • 0 in reply to Charles Tsai
    Prodigy 50 points

    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.

  • 0 in reply to mskjons
    TI__Guru**** 183066 points

    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?

  • 0 in reply to Charles Tsai
    Prodigy 50 points

    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.

  • 0 in reply to mskjons
    TI__Guru**** 183066 points

    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. 

  • 0 in reply to Charles Tsai
    TI__Guru**** 183066 points

    Hi,

      Do you have any update? I will close the thread for now. If you have any update, just write back and the thread will automatically reopen and I will be notified.