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.

TMS320F28379D: flash erase/write busy bit is not set

Part Number: TMS320F28379D
Other Parts Discussed in Thread: C2000WARE

Hello,
customer uses the TMS320F28379D. When executing the Flash routine he don't see that the busy bit is set and he had implemented manual delay to be ok not to interrupted the Flash routine.

Regards, Holger

  • Holger,

    I would like to know the context of this. Is customer not able to erase and program the Flash successfully using the Flash API library (C2000Ware_x_xx_xx_xx\libraries\flash_api\f2837xd)?
    And hence started to look at the busy bit?

    As long as the customer application waits for the FSM operation to be complete using Fapi_checkFsmForReady() as shown in below code snippet and is successfully able to erase/program the Flash successfully, there is no need to insert additional delay.

    //
    // Wait until FSM is done with erase sector operation
    //
    while(Fapi_checkFsmForReady() != Fapi_Status_FsmReady){}

    If above code is used to wait for FSM to complete the task and still not succeeding in erase/program, then we need to debug it in a different way. Let me know.

    Thanks and regards,
    Vamsi
    Flash API wiki: processors.wiki.ti.com/.../C2000_Flash_FAQ

  • Hello Vamsi,
    yes, he uses the „Fapi_checkFsmForReady“ API but he get allways Ready back. It works if you only call the erase function once. If you call the earse function a couple of times it runs in a timeout. Customer looked at the busy bit and it is never set. Then he implemented a delay of 55ms and the it works. Could you see that busy bit is set when erasing?

    Regards, Holger

    Regards, Holger
  • Holger,

    Application has to wait on this function after every erase or program function call.

    Busy bit works as expected - no need to doubt that. Is customer checking the busy bit manually in the memory window? Erase happens pretty fast on this device (see datasheet spec) - you may not notice the busy bit toggle in memory window.

    I did not understand the timeout that you mentioned. Could you please explain in detail?

    Thanks and regards,
    Vamsi
  • but what could be the reason for a timeout in case of serveral erase procedures.

  • Holger,

    Please provide a code sample to show the timeout.  Then I can help.  

    Can you confirm whether they are waiting or not for FSM to complete the current task after every function call (erase and program functions)?  I asked this earlier.  I can help you further, if you answer this.  

    Thanks and regards,
    Vamsi

  • Holger,

    Since I did not hear from you, I assume the customer is able to avoid the timeout with the suggestion that I provided. I am closing this thread. You can open a new thread if required.

    Thanks and regards,
    Vamsi
  • Vamsi,
    sorry, I was on vacation the last to weeks.

    Here the code snippet:

          EALLOW;
          eAPIResult = Fapi_issueAsyncCommandWithAddress (Fapi_EraseSector, (SMX_U32 *) u32SectorStartAddress);
          EDIS;

          SMX_U32 *pu32AddrPtr, u32val;
          pu32AddrPtr = (SMX_U32 *) 0x5F82A;
          u32val = *pu32AddrPtr;
          DB_PRINTF(("FMSTAT (0x5F82A) = 0x%04x%04x\r\n", (SMX_U16) (u32val >> 16), (SMX_U16) (u32val)));
          u32val = *pu32AddrPtr;
          DB_PRINTF(("FMSTAT (0x5F82A) = 0x%04x%04x\r\n", (SMX_U16) (u32val >> 16), (SMX_U16) (u32val)));
          u32val = *pu32AddrPtr;
          DB_PRINTF(("FMSTAT (0x5F82A) = 0x%04x%04x\r\n", (SMX_U16) (u32val >> 16), (SMX_U16) (u32val))); 

    Printf-output:
    0x8405 MEMORY ERASE
    FMSTAT (0x5F82A) =0x00000000
    FMSTAT (0x5F82A) =0x00000000
    FMSTAT (0x5F82A) =0x00000000

    Regards, Holger

  • Holger,

    I don't see customer waiting for the FSM operation to complete. As shown in the Flash API guide and mentioned in the Flash API wiki, application should wait for the FSM to complete the erase operation as shown below using Fapi_checkFsmForReady() function.

    oReturnCheck = Fapi_issueAsyncCommandWithAddress(Fapi_EraseSector, Sector Address);

    while (Fapi_checkFsmForReady() != Fapi_Status_FsmReady) { }

    Please ask customer to make this change and see if that helps.

    Thanks and best regards,

    Vamsi

  • Hello Vamsi,
    he uses these functions. It works when erasing one section but erasing more sections there will be errors. Btw, how long would be the busy flag set?

    Here the code he uses in production:

    RESULT TMS320_F2837x_FLASHEraseSector (SMA_U32 u32SectorStartAddress, SMA_U32 u32TimeoutIterations)
    {
       RESULT Result = BSP_ERROR;
       Fapi_StatusType eAPIResult;
       boolean bAbort = false;
       SMA_U8 u8WaitLoop; 

       /* set active flash bank */
       EALLOW;
       eAPIResult = Fapi_setActiveFlashBank (Fapi_FlashBank0);
       EDIS;

        /* initiate erase command */
       if (Fapi_Status_Success == eAPIResult)
       {
          EALLOW;
          eAPIResult = Fapi_issueAsyncCommandWithAddress (Fapi_EraseSector, (SMA_U32 *) u32SectorStartAddress);
          EDIS; 

          /* WORKAROUND: For unknown reasons function Fapi_checkFsmForReady     *
           * does not return a busy flag while writing is active. Thus we       *
           * stay here for the time given by spec (max. 55ms for a 32KW sector) */

           #define WAIT_ERASE_MS 55u 

          for (u8WaitLoop = 0u; WAIT_ERASE_MS > u8WaitLoop; u8WaitLoop++)
          {
             (void) bsp2_HWDTrigger (BSP_CHANNEL_0);
             TMS320_CPUDelay_us (1000);
          }

          /* End of WORKAROUND */ 

          /* wait until erase process has finished */
          while ((0UL != u32TimeoutIterations) && (false == bAbort))
          {
             if (Fapi_Status_FsmReady == Fapi_checkFsmForReady())
             {
                bAbort = true;
             }
             else
             {
                u32TimeoutIterations--;

                 if (0UL == (u32TimeoutIterations % 100UL))
                  (void) bsp2_HWDTrigger (BSP_CHANNEL_0)
             }
         }

          if (0UL != u32TimeoutIterations)
          {
             if (Fapi_Status_Success == eAPIResult)
             {
                Result = BSP_OK;
             }
          }

          else
             Result = BSP_ERR_FLASH_TIMEOUT;
       }
       return Result;
    }

    Regards, Holger

  • Holger,

    Erase times are provided in Table 5-20. Flash Parameters of datasheet.

    Are you saying that erase is taking more than 55ms for a 32KW sector?

    How many write/erase cycles did the device go through?

    Instead of above timeout procedure, if they simply wait on FSM using Fapi_checkFsmForReady(), does it ever complete erasing? OR is it stuck in the loop?

    while (Fapi_checkFsmForReady() != Fapi_Status_FsmReady) { }

    Thanks and regards,
    Vamsi

  • Hello Vamsi,
    the problem is that it runs to fast through Fapi_checkFsmForReady() like the busy bit is not set. For one cycle it is no problem but if you do several erase cycles then it runs into problem. 

    Regards, Holger

  • Holger,

    Please answer my questions:
    #1. Any estimate on the number of erases done?
    #2. Instead of above timeout procedure, if they simply wait on FSM using Fapi_checkFsmForReady(), does it ever complete erasing? OR is it stuck in the loop waiting on FSM to get ready?
    #3. When timeout occurs, what is the FMSTAT value for the failed erase operation?
    #4. Does timeout happen on the same sector everytime or does it differ?
    #5. When timeout occurs, what is the return value from the erase command?

    Note that erase can happen very fast than the time quoted in the datasheet. Datasheet number is conservative taking many factors in to consideration.

    Thanks and regards,
    Vamsi
  • here the answers:

    #1. Any estimate on the number of erases done?
    The effect is independent on the number of erases. Nevertheless, I guess I will have erased the device less than 50 times so far.

    #2. Instead of above timeout procedure, if they simply wait on FSM using Fapi_checkFsmForReady(), does it ever complete erasing? OR is it stuck in the loop waiting on FSM to get ready?
    Erase is always completed but I do NOT get the busy flag at all. Thus, I slip through the delay in its first iteration. This happens by using Fapi_checkFsmForReady as well as directly polling the register. Busy never goes high!!!

    #3. When timeout occurs, what is the FMSTAT value for the failed erase operation?
    I wish I had a timeout. ;-) As said before, busy never occurs and I have to add a delay of several ms manually.

    #4. Does timeout happen on the same sector everytime or does it differ?
    see above; effect is independent on the sector.

    #5. When timeout occurs, what is the return value from the erase command? Note that erase can happen very fast than the time quoted
    According to Fapi_checkFsmForReady the erase procedure just takes some microseconds (see my comments above). I just never get the busy bit high, neither at erasing nor at writing. Is there any internal signal that might “block” the erase bit from going high?
  • Holger,

    It is clearly mentioned in datasheet spec that erase time includes CPU verify times as well (meaning the time it takes to do blank check by CPU is also included in those numbers).

    As I mentioned, in this Flash technology, erase operation alone happens pretty fast (I don't want to mention a number here, apart from the number given in datasheet). Don't try to catch the FSM busy bit to show as active.

    From your words, it is clear that erase is happening fine and the blank check is passing and there is no timeout. It tells me there is nothing to debug here.

    If you want to discuss further, you can align with me on a time to have a call.

    Thanks and regards,
    Vamsi
  • Hello Vamsi,
    I ordered the customer a C2000 Experimenter Kit and he should run our flash example on it. This will be done next week. I will let you know. THen may be conf call is needed.

    Regards, Holger
  • Holger,

    I am closing this post. If we need to discuss further on this, please use the "Ask a related question" feature to start the discussion.

    Thanks and regards,
    Vamsi