• State Resolved
  • Locked Locked
  • Replies 12 replies
  • Answers 3 answers
  • Subscribers 83 subscribers
  • Views 1680 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.

Original question:

TMS320F28377D: There have error log as blow picture, and from the MAP file we can not find the address.

TMS320F28377D: The program only wrote the memory at 64 bits intervals using DFU.

Lian Wu
Genius 5250 points

Part Number: TMS320F28377D
Other Parts Discussed in Thread: CONTROLSUITE, C2000WARE

Dears：

We follow the before issue to check :e2e.ti.com/.../678896

We check the Sector F to erase the memory which is OK using CCS on-chip Flash.

And we debug the application program through the DFU (kernel 190) step by step, and we find the program only wrote the memory at 64 bits intervals.

We thought it is the key problem.

Then we use CCS to write the txt file to Flash directly, and the written memory as below picture:

Why do the issue happen?

We use the kernel file under C:\ti\controlSUITE\device_support\F2837xD\v190

Could you kindly help to give some advice?

Thanks a lot!

Best regards

Luck Wu

  • 0
    TI__Mastermind 32995 points
    Hi Luck,

    The Flash API on F2837x always programs 64-bits at a time. This is inherent to the technology and flash wrapper on the device.

    Since you have been able to debug with the emulator connected, you should be able to see why it is skipping over every other 64-bits of memory.

    I would think it has something to do with your hex file. Make sure you are putting it in the correct hex file. You can see the POST BUILD steps of the CCS project for the kernel to see what is required to turn your flash application .out file into the proper hex file.

    Because the memory you are showing is getting updated together and is contiguous, it should be stored in the hex file and communicated to the USB device as a single block of data.

    The hex format contains things like: the block address, the block size, and the block data. You can see this in the kernel as well as in the TRM which describes the hex file data format. Please refer to this when debugging.

    Hope this helps!

    sal
  • 0 in reply to Sal Pezzino
    Genius 5250 points

    Dear Sal:
    Thanks for your suggestions, and we are checking hex file.
    Btw, we use hex2000 to turn .out file to .txt file. Is it wrong suffix file?
    Pls. give some advice about it.
    Thanks a lot!

    Best regards
    Luck Wu

  • 0 in reply to Lian Wu
    TI__Mastermind 32995 points
    Hi Luck,

    The file extension shouldn't matter. .txt is perfectly acceptable.

    Regards,
    sal
  • 0 in reply to Sal Pezzino
    Genius 5250 points
    Dear Sal:
    Is the material about hex format file?
    www.ti.com/.../spru513p.pdf (the part is 12.2.1)

    Thanks a lot!
    Best regards
    Luck Wu
  • 0 in reply to Lian Wu
    TI__Mastermind 32995 points
    Hi Luck,

    Yes. Section 12 describes the hex utility. In the sci flash kernels, we invoke the hex2000 utility as a post build processing step. You can see this in the CCS project properties.

    Regards,
    sal
  • 0 in reply to Sal Pezzino
    Genius 5250 points

    Hi Sal:

    We check the format of txt file, and we found nothing. And the below is our analysis and txt file.

    Copy of TI烧写问题确认.xlsx

    Could you kindly help to give some advice about the issue?

    Thanks a lot!

  • 0 in reply to Lian Wu
    TI__Mastermind 32995 points
    Hi Lian Wu,

    This is curious. I am not sure why the kernel would only be programming every other block.

    Can you load the kernel to the RAM, and then begin to send the flash application and begin to debug this. Load the kernel into RAM with the debugger connected. You can send the data via the Visual Studio project and set breakpoints in the kernel and the Visual Studio project to step through the process. I am not sure why the kernel would be skipping data to be programmed if it is formatted correctly in the hex file.

    Let me know what you see.

    Regards,
    sal
  • 0 in reply to Sal Pezzino
    Genius 5250 points

    Hi Sal:

    Ok, got it, and I will visit customer to debug it referred your suggestions.

    Btw, is there requirement about Version of Hex2000 and the below vresion?

    Thanks a lot!

    Best regards

    Luck Wu

  • 0 in reply to Lian Wu
    TI__Mastermind 32995 points
    Hi Luck,

    There should be no changes in the Hex2000 which effect this.

    I recommend using the latest version that is available in C2000Ware.

    Regards,
    sal
  • 0 in reply to Sal Pezzino
    Genius 5250 points

    Hi Sal：

    We want to debug the kernel step by step, however, when we use Flash programmer to communicate it, and the code is always in the below picture's line. Could you kindly help to give some advice to debug the kernel?

    And we use the below program.

    ..\ti\controlSUITE\device_support\~Utilities\serial_flash_programmer

    ..\ti\controlSUITE\device_support\F2837xD\v180\F2837xD_examples_Dual\F2837xD_sci_flash_kernels

    Best regards

    Luck Wu

  • 0 in reply to Lian Wu
    TI__Mastermind 32995 points
    That is because as you single step you also need to single step the serial flash programmer. If the PC has finished sending a byte and is waiting for a response, and if the device missed the character, it will sit in an infinite loop.

    You need to debug the host and device together to advance the program correctly.

    Also, are you using the latest release in C2000Ware? You may wish to try this. If this is an issue with the kernel, it may have already been corrected.

    Regards,
    sal
  • 0 in reply to Sal Pezzino
    TI__Mastermind 32995 points
    Are you using the latest kernel in C2000Ware? I am not aware of the bug you are seeing, but it may have been fixed in a newer release.

    Regards,
    sal