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.

TMS320F28075: A question to failed programming the flash at some address

Part Number: TMS320F28075


Dear Vamsi,

This is Hardy. Following is my customer's question to failed programming the flash at some address.

Please find the detailed here:

We encountered a problem in the upgrade process, we found that there is always a random address not write data, resulting in upgrade failure;
For example, one of the upgrade files is written to: address 0xA7FFF, content 0x55FF, write only one content; because the regional address does not actually write the corresponding value, resulting in correction failure.
Debugging work done:
1) Prove that the address can be written:
When there is data to be written to other addresses, we will rewrite the address to 0xA7FFF, by reading the address online to prove that the address can be normal to write data;
2) Eliminate program impact
Because each write to 0xA7FFF address, are not written into, so after debugging each write to 0xA7FFF address, the actual write when the address plus 1, or add 0xF, or to other addresses, can be found Write 0x55FF correctly;
Question: Are there any addresses that will be restricted?

Thanks and best regards,
Hardy

  • Hi Vamsi,

       The same problem as above.  

       This is another example. Each time the data is written from address 0x88DD9, the first seven are not written in, but the following address data can be written.

     

    This is written before

    This is written after

    Thanks and best regards,

    Xin

  • Hi Vamsi,

       I upload the screen shot here:

    This is written before

    This is written after

    Thanks and best regards,

    Hardy

  • Hardy,

    Will look in to this and get back to you tomorrow.

    Thanks and regards,
    Vamsi

  • Hardy,

    What is the error (return value from  Fapi_issueProgrammingCommand()) that the user got when the program operation failed?  

    Also, check for FMSTAT value using Fapi_getFsmStatus() function once FSM is done with the Flash program operation.  Return value from Fapi_getFsmStatus() function would be zero (check FMSTAT register) if the program operation succeeds. 

    See below code snippet:  In this code, oReturnCheck and oFlashStatus give the clue for further debug.  

    Fapi_StatusType            oReturnCheck;
    Fapi_FlashStatusType   oFlashStatus;

    .

    .

    .

    //Issue program command using Fapi_AutoEccGeneration

    oReturnCheck = Fapi_issueProgrammingCommand((uint32 *)u32Index, Buffer+i, 8, 0, 0,                                                                                                                                   Fapi_AutoEccGeneration);

    // Wait until the Flash program operation is over

    while(Fapi_checkFsmForReady() == Fapi_Status_FsmBusy);

    if(oReturnCheck != Fapi_Status_Success)

    {
         // Check Flash API documentation for possible errors
         Example_Error(oReturnCheck);
    }

    // Read FMSTAT register contents to know the status of FSM after

    // program command to see if there are any program operation related errors

    oFlashStatus = Fapi_getFsmStatus();

    Looking at the addresses at which the program operation is failing, I guess the user is not programming all the 64-bits of a 64-bit aligned memory at the same time using Fapi_AutoEccGeneration mode.  

    We can debug further in today evening's conference call.

    Thanks and regards,

    Vamsi

  • Vamsi,

    Is it in Fapi_DataAndEcc mode?

    Thanks and best regards,
    Hardy
  • Hardy,

    Fapi_DataAndEcc programming mode also requires to program 64-bits at a time on a 64-bit aligned memory.  As you know, once ECC is programmed for a given 64-bit aligned memory, programming that 64-bit location again (even changing some bits from 1s to 0s) is not possible until an erase is done.  

    Thanks and regards,
    Vamsi

  • Vamsi,

    Understand and thanks for your great support.

    Thanks and best regards,
    Hardy
  • Hardy, Xin,

    Since we found and fixed the issue in customer's application during our debug sessions early this week, I am closing this thread.

    FYI for others: Customer tried to program an already partially programmed (including ECC) 64-bit aligned Flash location. It will fail since the new ECC will collide with the existing ECC.  I asked customer to program a 64-bit aligned location all at once and then everything worked fine.

    Thanks and regards,
    Vamsi