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.

TMS320F28335: Depletion problem

Part Number: TMS320F28335
Other Parts Discussed in Thread: C2000WARE

Dear sir/madam,

We work with TMS320F28335 on many products and we didn't have the depletion problem until now. Unfortunately we faced this problem for the first time in a very important product. We burn it as usual with your FLASH API library and out of the blue we got this error. There was no power failure or Erase stop in the middle of process. No external event. I also tried your tips (attached at the end) and failed to recover.

My manager and I are now really concern about the reliability of this device. How can we assure such a problem will not happen again? I saw in your site that many users have this problem. And the only solution you have is to replace the device??? No way to prevent this problem to happen in advance? Just to remind you, the Flash API library supplied by you.

I saw also there is also an issue regarding balance sectors. Can this feature assist us somehow?

I suggest that you will write an application note about this problem and how to avoid it BEFORE it happens.

Details on the device:

From CCS after Reset based on your previous requests:

After Depletion command:

Thanks,

Zeev Gaaton

  • For some reason I failed to transfer CCS behaviour.
    After RESET All addresses between 0x33FF80 -0x33FFFF contains 0xFFFF except address 0x33FFF6 = 0x73, 0x33FFF7 = 0x8100.
    After Depletion command all adresses above contain Zero. The following message is displayed:
    "C28xx: Error occured during Flash operation: Timed out waiting for target to halt while executing FlashAPIInterfaceV2_10.out
    FlashProgrammer: Error when performing depletion recovery. Flash operation timed out waiting for the algorithm to complete. Operation cancelled."
    Zeev
  • Hi Zeev,

    The Flash_API guide in C2000ware goes into detail on ways to avoid depletion, directory below. Depletion occurs when the flash erase API process is halted before completing (i.e. ISRs are still enabled, power loss issue, etc.).

    C:\ti\c2000\C2000Ware_1_00_06_00\libraries\flash_api\f2833x\28335\docs\Flash2833x_API_Quickstart.pdf

    Could you please answer some questions for me to help understand why/how the device got into this state:

    Could you further explain your flash erase/programming process? Before re-programming, are you erasing the entire flash bank or erasing sector-by-sector? Have you implemented some flash erase time-out functionality into your application that could be interrupting this process? Are you servicing a Watchdog (internal or external) within your application? Are global interrupts disabled before calling the flash API functions (step 9 in guide)?

    Could you further explain the device behavior you were seeing prior to executing the depletion recovery algorithm? Were there any errors within CCS? When you had initially erased the device, did you check the status value the API function returned (step 14 in guide)?

    Also, could you verify that your flash wait-states are set properly according to the table below (FBANKWAIT register)?

    I’m not familiar with balance sectors, but will try to get back to you on this.

    Best,

    Kevin

  • Hi Kevin,

    I apologize for my late answer.

    We have an older version of Flash API (February 2008). I will compare it to the new version.

    On Flash we have several independent programs. Therefore we erase sector by sector.

    Since Erase is a separate task, then there is no time out. One Erase operation per program.

    We have no watchdog or timeout during this process, but it looks like the global interrupts are not disabled. I will check it and let you know.

    I am using a PC program, which communicates with on board burn program. We check the status returned by the Flash library and announce if there is a problem. Of course the problem started when we got this message. Then I tried to investigate it with CCS, but then it was too late, the depletion failed.

    I will check also the wait state issue.

    Thanks for your assistance

    Zeev

  • Hi Zeev,

    No worries.

    The waitstates only affect flash reading, so this shouldn't actually be a concern. My mistake.

    Do you know which flash function you saw fail? And so I understand, you're saying you were not able to capture the fail status then?

    Have you tried running the depletion algorithm on the unit several times, or is the device locked at this point (i.e. CSM passwords unknown)? Sometimes this can bring a unit out of depletion.

    This prior post goes into details of balanced sectors: e2e.ti.com/.../395230

    The idea is you could avoid erasing certain balanced sectors to help handle power faults. For example, keeping BOOT-loader code on balanced sections that won't be erased/re-programmed and having re-proggrammable system code on two other balanced sections.

    Best,
    Kevin
  • Hi Kevin,

    First of all, I checked if interrupts are disabled during erase process. The interrupts are disabled: DINT command before the erase command and EINT afterwards.

    When the erase failed, I didn't catch the fail status.

    I didn't touch the CSM passwords at all. I ran the depletion algorithm several time without success.

    Regarding the balace sectors, I don't understand yet what is best to do. Let assume:

    1.  I have two independent programs and each program has 2 sectors.

    2. The Flash contains four sectors. Sector A is balanced with Sector D and Secor B is balanced with Sector C.

    Therefore there are two ways to arrange the two programs in Flash

    a. First program in Sectors A, B. The second program in Sectors C, D

    b. First program in Sectors A, D. The second program in Sectors B, C

    Which way do you recommend to implement? Does the recommended way will have more immune again depletion problem?

    Best regards,

    Zeev

  • Hi Zeev,

    OK, that's good. Please just make sure you disable interrupts each time before you call the erase function. It seems your device may be in a deep state of depletion and cannot be recovered.

    Storing the erase fail status could give us a better idea of what went wrong in the future. It's sort of hard to pin it on one thing right now.

    A couple other things you could verify are discussed in step 1, 7, and 8 in the Flash API guide:

    step 1: Check that the proper CPU rate you are running at is configured in API_Config.h

    step 7: Check that Flash_CPUScaleFactor is properly initialized in your application. I'd expect this to already be right, but still worth checking.

    step 8: Set the Flash_CallbackPtr to NULL in your application if you are not using it. In the Flash_API example it's not set to NULL by default.

    Are you using a F28335? It should have 8 sectors, based on the datasheet.

    I believe implementation B is better, i.e. put programs in the same balanced sectors. That way erasing the sectors for one program will not affect the flash sector contents for the other program. However, how much benefit you really get out of this will depend on your application and what your two programs do. The prior E2E post I linked to earlier was discussing the implementation of a secondary boot loader living in flash to verify the contents of other flash sectors.

    Best,
    Kevin
  • Hi Kevin,

    Thanks for the tips.

    Zeev