• State Resolved
  • Locked Locked
  • Replies 10 replies
  • Subscribers 31 subscribers
  • Views 1481 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

USB DFU binary load creation/corruption/fail

Matt Buonadonna
Intellectual 380 points
Other Parts Discussed in Thread: UNIFLASH, LMFLASHPROGRAMMER

We are encountering a problem when we load a .bin file via the ROM boot loader usb dfu. The problem is when the device is loaded via DFU the bin image is corrupted causing the device to be bricked.

Target processor: TM3C1233H6PM on a custom board
IDE: CCS V6.0.0.00190
Uniflash version: 3.1.0.00026

Some things that we managed to rule out:

  1. When the .bin image is small (ie <32k) the system runs fine after performing a DFU.
  2. When the .bin image is big (>32k) the system fails after performing the DFU and is "bricked"
  3. When the .out file is loaded via JTAG regardless of size the system runs as expected
  4. When the .bin image is loaded via JTAG and is small (<32k)the system runs as expected
  5. When the .bin image is loaded via JTAG and is big(>32k) the system fails and is "bricked"
  6. The memory dumped after loading the .out via jtag compared against the created .bin file from the compiler are identical.
  7. The memory dumped after loading the .bin file via DFU against the created .bin file from the compiler are different.
  8. The memory dumped after loading the .out file via JTAG against the created .bin file from the compiler are identical.
  9. The device uses a battery but was in tolerable limits to allow device flashing.
  10. The USB DFU process uses an external 16mHz oscillator of better then recommended precision to clock the USB since the internal clock cannot support USB.

Questions:

  1. I recognize that the 32k limit is a common limit when using the free license for CCS but I am currently on an evaluation license with greater then a month remaining. However, if I was limited to 32k, does the compiler not output an error saying the limit is exceeded?
  2. We have a valid license and the results are the same. Are there other project settings that need to be taken into consideration when building a "large" project?
  3. Any other courses of action that we need to take in order to fix this problem?

-Matt

  • 0
    Intellectual 380 points

    Another test we ran was perform the DFU via a UART connection. The results were the same as the USB DFU update. Bin was corrupted and device was essentially "Bricked"

  • 0 in reply to Matt Buonadonna
    Intellectual 380 points

    So I want to bump this post to see if ANYBODY has an idea on to how to fix this problem. We are still encountering it.

    If additional information is needed let me know and I will get it for you all.

    -MattB

  • 0 in reply to Matt Buonadonna
    Intellectual 380 points

    Adding additional info.

    We turned on optimization to reduce the code footprint and managed to get it down to just below 30k.

    Performing the DFU process using UniFlash over USB and the "small" flash image was successful and causes no problems.

    We added just  a bit more code to the project to push it over the 32k limit and, sure enough, performing the DFU process "bricks" the device.

  • 0 in reply to Matt Buonadonna
    TI__Genius 13095 points

    Matt,

    I looked at our CCS/UniFlash implementation and do not see anything that would imply a 32K limit. I don't have access to the underlying library that I call into, so I will need to do some research to see if there are any limitation on that component.

    Would it be possible for you to send me the programs (working and not working) that you are using for testing? so that I can try debugging it on my end. And when you say the device is "bricked", is there any way to recover from it, or does it not work anymore?

    Also, have you tried LM Flash? (http://www.ti.com/tool/lmflashprogrammer). The implementation should be the same, so I'm curious to see if it works in LM Flash versus UniFlash.

    Thanks,

    Ricky

  • 0 in reply to Ricky Lau
    Intellectual 380 points

    Hello Ricky,

    Thanks so much for getting back to me on this issue. I'll answer your questions in order.

    By "send you the programs" do you mean you want our .bin .out .hex .map files we use to upload to the device? I can send you those no problem. What we are "using for testing" are CCS 6.0.1.00040 to build and load our project onto the board and UniFlash 3.1.0.00026 to DFU our device.4863.aerosmith.zip

    By "bricked" I mean from a user standpoint. IE if a user were to follow the DFU procedure to get the device into DFU mode and run UniFlash to flash a new .bin to our device it would be unresponsive to the user. From an engineers stand point I can recover the device by attaching a JTAG and reloading the program from CCS "un-bricking" the device.

    I have not tried LM Flash since (I thought) it was a legacy firmware upgrade utility. I will get it though and try it out and see what happens.

  • 0 in reply to Matt Buonadonna
    Intellectual 380 points

    Solution found!

    Thanks to Ricky for pointing out to me that LM Flash Programmer is not a legacy app for updating device firmware like I originally thought.

    It turns out that when using UniFlash our device is bricked according to the results listed earlier. HOWEVER, if we use LM Flash programmer the system can be DFU'ed via USB and recovers as expected. 

    Ricky,

    You mentioned that the implementation is the same between UniFlash and LM Flash programmer. But with what I am seeing on our device when programmed using one vs the other there are differences. If you would like I can post memory dumps from our device with one from being DFU'ed via UniFlash and the other via LM Flash Programmer. Again, thank you for your assistance in this matter.

    -Matt

  • 0 in reply to Matt Buonadonna
    TI__Genius 13095 points

    Matt,

    If you can provide the memory dump, it will help a lot.

    Although LM Flash can still be used, I'm not sure if it will be support going forward. UniFlash is meant to be the tool for all TI Flash devices going forward, so we definitely want to fix any problems with the implementation.

    Thanks,

    Ricky

  • 0 in reply to Ricky Lau
    Guru 26105 points

    Hi Ricky,

    FYI: the unlocking Tiva micros is still a missing feature in UNIFLASH compared with LMFlash.

    Petrei

  • 0 in reply to Petrei
    TI__Genius 13095 points

    Petrei,

    The Debug Port Unlock feature was adding to UniFlash already; please refer to UniFlash 3.1.

    Is that the feature you are talking about? or something else? We are aiming for feature parity with LM Flash so please let me know if you find other missing features.

    Thanks,

    Ricky

  • 0 in reply to Ricky Lau
    Guru 26105 points

    Hi,

    Thanks for the info - I didn't updated to the new version up to now.

    Petrei