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.

TMS320F280021: FMSTAT error after programing with API.

Part Number: TMS320F280021
Other Parts Discussed in Thread: TMS320F280025, , UNIFLASH, C2000WARE

I have a problem with some TMS320F280021 as well as some TMS320F280025. I have a program that connects over JTAG to the chip, and then downloads a bootloader to program data into it. For some devices everything is working fine, but some always fail while programming.

I tried to program the devices with UNIFLASH and our XDS110 DEBUG PROBE, there everything was working well, so the Chips are not broken.

I tried to erase the device multiple times before the writing, or erase with UNIFLASH before writing with our program. In all cases the blankcheck was successfull, but the programming failed at the same address.

I tried to add a waiting time between each 64 bit write, this did not affect the programming and they failed at the same address as always.

The error is that the FMSTAT is not zero after the programming call, the bits 12 & 4 are set.

PGV [12]: Program verify. When set, indicates that a word is not successfully programmed after the maximum allowed number of program pulses are given for program operation

CSTAT [4]: Command Status. Once the FSM starts any failure will set this bit. When set, this bit informs the host that the program or erase command failed and the command was stopped. This bit is cleared by the Clear Status command. For some errors, this will be the only indication of an FSM error because the cause does not fall within the other error bit types.

I checked tha Flash API reference guide, but there I found nothing that would explain this behavior.

Is there anything else that I can try, or does anyone have an Idea what could cause this?

  • Tobias,

    Please try the flash programming example given in C2000Ware and let us know whether or not it works for you as-is.  

    If that works, then you can compare your code with that example.

    1) Did the program function return any error?  I got that FMSTAT is not zero.  

    2) What is the address you are trying to program and what is the length and programming mode used for program function?

    3) Is there a wait loop after the program command waiting for the program operation to complete?

    4) Is Flash API executing from RAM?

    Thanks and regards,
    Vamsi

  • Hallo Vamsi,

    Up till now I did not try it with the example, I will do it and then tell you the result. I used the example as guideline for my bootloader, in the attached picture is a diff of the two functions.

    Regarding your other questions:

    1. Fapi_issueProgrammingCommand() returned with Fapi_Status_Success. But afterwards oFlashStatus = Fapi_getFsmStatus(); was not zero.

    2. I use the Fapi_AutoEccGeneration mode and try to program in writes of 64 bit. I changed it to the smaller writes to be also usable for the OTP programming. The error does not happen always at the same address, but there are some that will cause it most of the time. One chip had the errors at 0x00080530, 0x000808B4 and 0x00080EBC, but I didn't try to get all possible errors.

    3. There is no timed waiting loop, instead I poll for Fapi_checkFsmForReady(). I also tried a waiting loop additionaly to the polling, but it did not improve the stability.

    4. Everything is running from RAM.

    Thanks for the help,

    Tobias

  • Hallo Vamsi,

    During the testing of the example I found that my clocks were wrongly configured, after fixing this the programming worked on all devices.

  • Hi Tobias,

    Thank you for posting the update/resolution.  That helps others that may refer to this post.

    Thanks and regards,
    Vamsi