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.

TMS320F28377S: Urgent Error Using C2000 chip with Serial Flash Programmer

Part Number: TMS320F28377S
Other Parts Discussed in Thread: UNIFLASH, C2000WARE

Hello,

I am working with a customer right now who has run into a critically urgent error that affects their production using the TMS320F28377S.  I'm attaching their description below here.  I have also attached a picture of the error message seen on their software.  We are looking to resolve this error ASAP, so please let us know the next steps here, thank you for the support.

We are using a C2000, TMS320F2837xS chip for our product. One of the features of the product is the ability to program the flash over serial. TI provides a program called serial flash programmer which we have been using for almost 3 years without a problem. Recently we ran into an issue programming a few boards where the download will complete but will have a verify_error at address 0xa800 as the screenshot attached. Some interesting notes about the issue:

  • Not every chip/board fails. I was able to have a board successfully update 20 times without this issue.
  • One board I was able to program 4 times and then on the 5th time it would fail and no longer be able to upgrade.
  • All failing boards are able to be programmed over JTAG without an issue.
  • The boards which fail seem to be partially running, ie. Our heartbeat LED blinks but our communications set and other features do not function.
  • Boards which are failing are able to be programmed with flash that is less than 300 kb in size and will still fail on larger files.

I attached the firmware we are using.

Here is the URL to the documentation I’m using. It’s not 100% clear and I’ve been reverse engineering the serial output vs the source code vs the documentation.

https://www.ti.com/lit/an/sprabv4d/sprabv4d.pdf?ts=1614204909720&ref_url=https%253A%252F%252Fwww.google.com%252F  

  • Domenick,

    Did it start failing after they made some changes to their application?  

    Based on the error address, looks like the customer mapped some initialized section to RAM in their linker cmd file.  Please check and confirm.

    Please note CCS flash plugin, Uniflash and Serial flash kernels do not guarantee loading code to RAM - They are developed to support fully embedded flash applications.  Meaning, all the initialized sections should be mapped only to flash and not to RAM.  If any code/data needs to be in RAM, they need to be copied to RAM at runtime.  

    You said you attached the firmware - I think you missed to attach it.  Please check.  

    Thanks and regards,

    Vamsi

  • Hi Vamsi,

    We have discussed the code offline I believe, and the customer did not make changes to their application.   I will check the RAM section.  Is there anything else to look for?

  • Domenick,

    Thank you for confirming that customer did not make any changes in their application before seeing this failure.  This means, it went from passing to failing without any change in the application image. 

    1. Did they make any change in the kernels before this failure started showing up?

    2. Did they align all the sections mapped to flash in the linker cmd file on 128-bit boundary (as shown in the flash based linker cmd files in the C2000Ware - ALIGN(x) is used to align)? 

    3. Did they try kernels provided in the latest C2000Ware available at this time (C2000Ware_3_04_00_00\device_support\f2837xs\examples\cpu1\F2837xS_sci_flash_kernel)?  If not, would suggest to try once.  They said they have been using the kernels from 3 years.  I would suggest to check the latest kernel once.  There are couple of bug fixes done.

    Regarding the source: Anu is checking the code that you sent.  She will get back to you.  

    Let me know on the RAM usage once you check with the customer.

    Thanks and regards,
    Vamsi

  • Domenick,

    I looked at the files that you sent offline.  They are in hex.  Please send actual source files for us to review.

    Thanks and regards,
    Vamsi

  • Domenick,

    I am closing this post since I did not hear back from you.  

    If you need more help on this topic, please open a new post and reference this post.  Our team will help you.

    Please note: I will be out of office up to March 16th.

    Thanks and regards,

    Vamsi