• State
  • Replies 6 replies
  • Subscribers 84 subscribers
  • Views 99 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

Original question:

TMS320F28375D: TMS320F28375D: SCI BOOT Mode (FMSTAT Register contents:01010)

TMS320F28375D: SCI Boot failure with FMSTAT=01010

Hang Yang
Intellectual 2231 points
Part Number: TMS320F28375D
Other Parts Discussed in Thread: C2000WARE, UNIFLASH

Tool/software:

Hi Experts,

My customer met a very similar issue. 

They are testing TI example (serial flash programmer + exmaple kernal and app in the C2000ware) on their own board and sees a programmer error as below.

However, if they use C2Prog, the process is successful. 

Any idea what might be the issue here?

Regards,

Hang.

  • 0
    TI__Intellectual 2231 points

    The FMSTAT may indicates a hardware issue. However, it cannot explain that why programming with C2Prog is successful. 

  • 0 in reply to Hang Yang
    TI__Genius 11825 points

    Hi Hang,

    Is this version of the Serial Flash Programmer above from the latest C2000ware?

    Thanks and regards,

    Charles

  • 0 in reply to Charles Roberson
    TI__Intellectual 2231 points

    It’s 5.02 and 5.03

  • 0 in reply to Hang Yang
    TI__Intellectual 1520 points

    Hang,

    Could you please try the debugging steps discussed in this post and report your results?

    Best,

    Alex

  • 0 in reply to Alex Wasinger
    TI__Intellectual 2231 points

    Hi Alex,

    We've done some tests similar to the related thread as below.

    - Tried using a different kernel from customer. There is still the same FMSTAT 01010 error, but at a different address 0x8b940

    - Read the memory when the failures happen, the flash has been erased, but in correctly programmed. Below is image when it fails at 0x82000

    - Since C2Prog is programming is successful, there should be no faulty flash cell in the range we concerned.

    - Jtag load of application (using example) via Uniflash is successful.

    These tests should cover some of the tests in the related thread. 

    Could you please share what we need to confirm/exclude next? This would be more helpful share the goal or idea along with providing specific steps since we have lag due to time zone. If you tell us the goal, me and customer can try to get it somehow if the specific steps don't work out. Nevertheless, it's appreciated if you can provide a specific step as reference.

    Note that the related thread ends up in FA return, but my customer already did the FA earlier. (The issue back then is triggering uncorrectable flash NMI. the board is the same to ones tested today) The FA concludes it as the pad crack issue. They switched to post PVC products that doesn't have the pad crack issue, but they still have problem flashing the device.

    Regards,

    Hang.

  • 0 in reply to Hang Yang
    TI__Genius 11825 points

    Hi Hang,

    For CCS next steps, are we confirming operation by:

    1) Setting the boot mode to 0x815A at address 0xD00. 

    2) Load the symbols for the kernel 

    3) Running CPU1 target

    4) Run the Serial Flash Programmer w/ example files (If able, Visual Studio access could help, executing the .sln file included with the project, C2000Ware_5_04_00_00\utilities\flash_programmers\serial_flash_programmer\serial_flash_programmer.sln, adding the arguments as through Debug->Properties->Configuration Properties->Debugging->Command Arguments). Example given in images below.

    Example files for kernel and application can be placed in this location: 

    C2000Ware_5_04_00_00\utilities\flash_programmers\serial_flash_programmer\serial_flash_programmer

    5) From CCS side, it would also help to have a memory window open and set to continuous refresh to see if the fields are being populated by the new application.

    Thanks and regards,

    Charles