• State
  • Locked Locked
  • Replies 9 replies
  • Subscribers 83 subscribers
  • Views 295 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.

TMS320F28069: Issue with DFU mode on F28069U models - device reverts back into DFU mode from Normal mode in Runtime

John
Prodigy 75 points
Part Number: TMS320F28069
Other Parts Discussed in Thread: UNIFLASH

Hello all,

We are now facing an issue in our firmware that is developed with F28069 DSPs which works with F28069U, F28069F, and F28069M models that are having USB enabled, so basically the overall design of the firmware is as below:

  1. Run-time code
  2. Boot-loader code

The Run-time code is the code that we are continuously developing and expanding, it utilizes various features of the DSP including the USB communication as a Virtual COM port.

The Bootloader works with a USB device firmware upgrade program published by Texas with very minimal changes.

Now the problem is we've been using this combination for over 3 years without any issues, but as our Run-time code is expanding and occupying more RAM and FLASH now we see that after the boot-up the Run-time code doesn't run and the device goes back in DFU mode! In our system, the DFU mode is made to happen only if a specific GPIO is pulled-down, but due to some strange reason, the Run-time code forces the DFU back.

One thing that we found is, once we totally disable the USB functionality in the Run-time code, by removing the usblib.lib and driverlib.lib and all the associated libraries of the USB the Run-time code works again, but of course, we lose the possibility of having the COM port which is not acceptible for our application.

So I'd like to know where should we start looking, as we tried various methods but with no success.

John

  • 0
    Prodigy 75 points

    Hi,

    Another update from my side:

    - I tried to program the Run-time code directly into the Flash and change the Linker to point to the initial part of the code and not the bootloader, and now the program is running, so basically it seems we are having one of the below problems :

    1. The Bootloader code fails to boot up as the Flash size is bigger, maybe it fails during the operation or the JTAG expires, or sth along these lines ( In my bootloader the JTAG is disabled )
    2. The dfuprog.exe program on the PC fails to properly send the hex to the bootloader
    3. The Run-time code somehow interferes with the bootloader and puts back the device in DFU mode again.

    I will await your review of this.

    John

  • 0 in reply to John
    TI__Guru 50430 points

    John,

    We have assigned the thread to USB flash programmer. Please expect response by tomorrow.

    Regards, Santosh

  • 0 in reply to Santosh Jha
    Prodigy 75 points

    Hello Santosh,

    Just wondering if there is any update on this. we are now stuck on this issue, please advise on that.

    John

  • 0 in reply to John
    TI__Guru 50430 points

      : Can you please take a look?

  • 0 in reply to Santosh Jha
    TI__Mastermind 30825 points

    John, 

    To narrow down on the issue, do you see any error related to uploading the data when you run the dfuprog.exe ? 

    You can run dfuprog without the quiet option so that it prints out messages related to uploading the application.

    Best Regards

    Siddharth

  • 0 in reply to Siddharth Deshpande
    Prodigy 75 points

    Hi ,

    Sorry for the delay, been very busy, so basically it seems the DFU prog puts the program on the device without any issue, however, my device remains in DFU mode and never gets out of it:

    So what do you think can be the issue?

    John

  • 0 in reply to John
    Prodigy 75 points

    to add a further note on this, I see the following warning when I compile my code, it was always there, even when the Bootloader was working fine, but now I'm worried that may the boot-loader fails to complete the CRC in run-time or sth along those lines.

    How can I eliminate this warning as well?

    John

  • 0 in reply to John
    Prodigy 75 points

    Another point that just got my attention is the Stack usage as can be seen in below, does this have any effect on the problem? 

    As can be seen, the ADC_Isr is fully occupied, but it's not clear to me if this is an issue or not, as CCS doesn't show any warnings or errors.

    John

  • 0 in reply to John
    TI__Mastermind 30825 points

    John, 

    Can you rerun with the verbose option (-v) on?  From the snapshot, looks like the hex file is not getting fully downloaded. 

    Other option is to export the memory using uniflash and compare it with the hex file that you have created. This will enusure if the hex file was downloaded successfully.

    Best Regards

    Siddharth