• State Answer Suggested
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 62 replies
  • Answers 1 answer
  • Subscribers 83 subscribers
  • Views 870 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.

TMDSCNCD28379D: USB Flash Programmer does not work with larger files

Brent Williams
Expert 1055 points
Part Number: TMDSCNCD28379D
Other Parts Discussed in Thread: C2000WARE, UNIFLASH

Hello,

I have a TMDSCNCD28379D and can successfully build the example led_ex1_blinky project for flash and use the hex2000.exe to generate a .dat file from the led_ex1_blinky.out. I have also successfully used the usb_flash_programmer.exe to program the flash with the generated .dat file using the following:

usb_flash_programmer.exe  F2837xD_usb_flash_kernels_cpu01.dat  led_ex1_blinky.dat

I then increase the size of the example program by adding a number of functions with asm(" NOP ") to simulate the size of a program we are porting (and want to use the USB flash programmer). The new size is led_ex1_blinky.out - 448608 bytes and led_ex1_blinky.dat - 182914 bytes.

When I try running the USB flash programmer again with the larger file  it fails short of writing all of the bytes. It always fails at 132928 bytes (tried a number of times).

Sending 182914 bytes of data from file led_ex1_blinky.dat...
Error sending bulk transfer: 0x0079
132928 out of 182914 bytes sent
USB operation failed!

If I use Code Composer it will erase, program flash, and run the new updated much larger file.

I did modify the linker command file consolidating sectors of flash into FLASHB. But again this works in Code Composer with the larger file. It also works using the USB flash programmer if I remove other code to reduce the file size to get back to the original code.

/* Flash sectors */
FLASHA : origin = 0x080002, length = 0x001FFE /* on-chip Flash */
FLASHB : origin = 0x082000, length = 0x026000 /* on-chip Flash */
FLASHI : origin = 0x0A8000, length = 0x008000 /* on-chip Flash */
FLASHJ : origin = 0x0B0000, length = 0x008000 /* on-chip Flash */
FLASHK : origin = 0x0B8000, length = 0x002000 /* on-chip Flash */
FLASHL : origin = 0x0BA000, length = 0x002000 /* on-chip Flash */
FLASHM : origin = 0x0BC000, length = 0x002000 /* on-chip Flash */
FLASHN : origin = 0x0BE000, length = 0x001FF0 /* on-chip Flash */

Is there a limit for file sizes that can be used with the usb_flash_programmer?

Any suggestions as to what to try?

Thanks for any help.

  • 0 in reply to Vamsi Gudivada
    Expert 1055 points

    I currently have a F2837x controlCard with a docking station.

    Looking at the following:

    C:\ti\c2000\C2000Ware_4_03_00_00\boards\controlCARDs\TMDSCNCD28379D\R1_3\TMDSCNCD28379D_180cCARD_pinout_R1_3.pdf

    I believe XRSn is pin 120?

    After resetting the processor in CC to start the USB flash programming this pin is currently at ~350 mV. I have a trigger set (falling edge).

    When running the usb_flash_programmer I do not trigger (i.e. line is staying at ~350 mV).

    It fails as described above.

    Are you able to replicate the issue with the CC project, source, and dat I provided?

    Thanks,

    Brent

  • 0 in reply to Brent Williams
    TI__Guru* 80730 points

    Brent,

    Thank you for the info.  The issue is not related to flash API.  

    I will ask our USB flash developer (asked him to try the project, but looks like he is not available) to file a ticket on this to debug this further so that they can release a fixed version in one of the later releases.

    Note: I also looped our developer with the compiler team to see if we can force every function to be on a aligned address.

    Thanks and regards,

    Vamsi

  • 0 in reply to Vamsi Gudivada
    Expert 1055 points

    Hi Vamsi,

    Thank you for the information.

    I just wanted a little clarification.

    You believe it to be an issue/bug with the USB flash kernel code?

    Specifically, you believe the flash kernel code is not properly aligning function(s) on an aligned address when writing the application .dat file to the FLASH so one or more functions are not aligned properly, and it causes the FLASH error?

    You have opened a ticket for the USB flash kernel developer to look at the issue and they will provide a fix in a new version update of the C2000 SDK?

    Is there any time frame on when this might be resolved?

    Is there a way I can keep track of the ticket or is that internal to TI? Not sure how to get status on the issue?

    Please let me know if there is a way to force every function to be on an aligned address.

    thanks,

    Brent

  • 0 in reply to Brent Williams
    TI__Guru* 80730 points

    Hi Brent,

    Regarding this issue, the first thing we plan to concentrate is to find a way to force every function to be on an aligned address.

    Yes, I do believe the issue is with the USB flash kernel code is not aligning the program data before passing it to the flash API.  Hence, is the error from the flash API.

    Yes, the USB flash kernel developer has to look at this - I don't know the time frame yet - it can be with the next C2000Ware release (not the one that is planned for this quarter).

    Yes, there is a way to track the ticket - Our team can provide that info to you next week.

    Thanks and regards,

    Vamsi

  • 0 in reply to Vamsi Gudivada
    TI__Guru* 80730 points

    Hi Brent,

    Regarding forcing the alignment on all the functions, our compiler team suggested as below:

    The nearest solution is to apply __attribute__((aligned(8))) to every function.   For details, please search the C28x compiler manual (https://www.ti.com/lit/pdf/spru514) for the sub-chapter titled Function Attributes.  To make that easier, wrap it in a macro.

    Please let me know if you need more info about this and I can loop in our compiler team to help you.

    Thanks and regards,

    Vamsi

  • 0 in reply to Vamsi Gudivada
    Expert 1055 points

    Thanks for the information Vamsi. 

    I will try the suggestion and let you know how it goes.

    Brent

  • 0 in reply to Brent Williams
    Expert 1055 points

    Hi Vamsi,

    Unfortunately, this did not resolve the issue.

    It is ultimately failing in the same place:

    Please see the attached updated file to verify I updated the code correctly. For every function (801 including main) I have the following declaration with the new attribute applied:

    void main()
    __attribute__((aligned(8)));
    void foo1()
    __attribute__((aligned(8)));

             ...

    7534.led_ex1_blinky.c

    Is there any other information that you need or something else I can try?

    Also are you able to duplicate the issue I am seeing?

    Thanks,

    Brent

  • 0 in reply to Brent Williams
    TI__Guru* 80730 points

    Brent,

    Thank you for trying our compiler team's suggestion.  

    Our USB expert (Siddharth) and Kernel expert (Charles) will debug this and try to release an update in fourth quarter of this year.  

    When they create the ticket, we will let you know the details on how to track it.

    Thanks and regards,

    Vamsi

  • 0 in reply to Vamsi Gudivada
    Expert 1055 points

    Thank you for the information.

  • 0 in reply to Brent Williams
    TI__Expert 4785 points

    Hi Brent,

    Currently filing the ticket, will be back with you on the details early next week for tracking. 

    Thanks and regards,

    Charles

  • 0 in reply to Charles Roberson
    Expert 1055 points

    Thank you for the update Charles.

  • 0 in reply to Brent Williams
    TI__Expert 4785 points

    Sent you a connect message for chat.

    Thanks,

    Charles