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: CCS v8.3.1/TMS320F28335: Error occurred during flash operation: Timed out waiting for target to halt while executing FlashAPIInterface28335V2_10.out

Part Number: TMS320F28335
Other Parts Discussed in Thread: C2000WARE, UNIFLASH

Whilst debugging (with break-points) a TMS320F28335 using a JTAG XDS510LC USB emulator, I get the following error

C28xx: Error occurred during flash operation: Timed out waiting for target to halt while executing FlashAPIInterface28335V2_10.out
C28xx: Error occurred during flash operation: Timed out waiting for target to halt while executing FlashAPIInterface28335V2_10.out
C28xx: Error: Error 0x20000024/-1135 Severe Error during: Register, Execution,  Unrecoverable emulation error
C28xx: Failed to remove the debug state from the target before disconnecting.  There may still be breakpoint op-codes embedded in program memory.  It is recommended that you reset the emulator before you connect and reload your program before you continue debugging
C28xx: Error occurred during flash operation: Could not read 0x0000900E@Data: target is not connected
C28xx: Error occurred during flash operation: Could not write 0x00009009@Data: target is not connected
C28xx: Error occurred during flash operation: Could not write 0x00009008@Data: target is not connected
C28xx: Error occurred during flash operation: Failed to run target while trying to execute FlashAPIInterface28335V2_10.out
C28xx: Error occurred during flash operation: Could not write 0x08834@Program: target is not connected
C28xx: Flash Programmer: Error encountered when writing to flash memory
C28xx: File Loader: Memory write failed: Unknown error

The debuggin have been working (i.e break point where being hit) until the above messages appeared presumable during an erase cycle.

The DSP is now un-responsive (effectively bricked).

Please can you suggest

1. What might have happened

2. How to re-cover the DSP

  • Hi Sam,

    Are you able to connect to the device now or not?

    If you are able to connect, can you try to execute this flash API based example and see whether it works or not?: C:\ti\c2000\C2000Ware_4_01_00_00\device_support\f2833x\examples\flash_f28335 

    Thanks and regards,

    Vamsi

  • Hi,

    Thanks for getting back. I'm NOT able to connect neither through CCS nor Uniflash

  • Hi Sam,

    Erase operation should not be interrupted.  Did that happen during your debug?

    Thanks and regards,
    Vamsi

  • Hi Vamsi,

    I didn't deliberately interrupt the Erase operation. I just watched and eventually saw the error messages appear in the CCS Console (mentioned above).

    On subsequent debugging attempt with the same emulator, I see the error message below

  • Hi Sam,

    Can you try one of the below two methods (snap from TRM) and see if you are able to connect?

    Thanks and regards,
    Vamsi

  • Hi Vamsi,

    Thanks for the suggestion. However,

    1. Flash on this DSP is not programmed with a password.

    2. The JTAG emulator fails to detect the DSP. I am not sure how to perform your suggestions when the DSP is not detected at all.

  • Hi Sam,

    When you said you kept breakpoints, where exactly did you keep them during the erase process?

    Thanks and regards,
    Vamsi

  • The breakpoint where kept in the application software. What I meant to say was these breakpoints were being hit on previous succesfull debugging sessions. During further debugging is when I saw the error messages (mentioned above).

    Is there any way the DSP can be reset either through a software tool or a hardware configuration?

  • Hi Sam,

    I feel the flash went in to depletion.  Options explained here: https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/757586/faq-f05-flash-what-is-depletion 

    Maybe the password locations also got invalid data.  Hence, I suggested about the ECSL previously.

    Thanks and regards,
    Vamsi

  • Hi Vamsi,

    Thanks for the reponse...Just to make it clear, my flash application IS NOT password protected. CSM feature IS NOT implemented. Does CCS v8.3.1 have the On Chip Flash Programmer feature. If not, which CCS version has it?

  • Hi Sam,

    Irrespective of whether CSM is implemented or not, if the depletion occurs, the CSM password locations may get invalid data.

    CCSv8 should have it; if not, you can use the latest CCSv11. 

    Please note:  If you need further assistance on this, the flash domain expert of this device will be available after a week.  He is out of the office now.

    Thanks and regards,
    Vamsi

  • I am using CCS v8.3.1 and the following is what I see in the project Debug configuration -> F28335 Flash Setings

    There are no options under the Depletion Recovery section. Does it mean the JTAG emulator needs to establish comms with the DSP as a basic before one can use the Depletion Recovery?On pressing the Debug, i get the same error message as menioned in previous post.

    Is it possible to return the DSP to TI for further investigation?

  • Update to the previous post.

    I have used UniFlash this time and able to see a Depletion Recovery button. Pressed it and gets the same error message as earlier

    ...

  • Sam,

    Thank you for trying the Depletion recovery.

    I will assign this to F28335 flash expert to guide you further.

    Thanks and regards,

    Vamsi

  • Sam,

    I want to clarify a bit on the CSM, I understand that you haven't intentionally loaded anything to the CSM but based on what you and Vamsi had discussed I think we are concerned there are non 0xFFFF values that got programmed in this space accidentally.

    After you connect, can you open a memory window to addresses 0x33FFF8 to 0x33FFFF and report back on what you see?  If the device is unlocked a read of these locations should give all 0xFFFF back.  However, if you see all 0x0000 this means that the device is locked.  We can proceed after that.

    Best,

    Matthew

  • Hi Matthew

    Thanks for your thoughts.

    May be I haven't explained this properly.

    If you look at my previous posts, the one thing that I keep re-mentioning is "UNABLE TO CONNECT" with the target. . What you and Vamsi have suggested are actions that could be performed once I connect with the DSP.

    So I will ask again. What can I possibly do to re-connect with the DSP?

  • Sam,

    Thanks for the clarification, let's put the device in check boot mode and see if that resolves the connection issue.

    If this doesn't help, if you could double click on the ccxml of your target config and then "test" the connection and report back the dialogue box output that will help me determine if the issue is at the debugger or on the device.

    Best,

    Matthew

  • Hi Matthew

    Thanks for the suggestion.

    Just to make sure, I have understood it correctly, to put the device in to "check boot mode", I have to set the following GPIOs using an external wire.

    GPIO87 (pin #174) = Short to Dig Gnd (Vss)

    GPIO86 (pin #173) = Short to Dig Gnd (Vss)

    GPIO85 (pin #172) = Short to 3.3V (Vddio)

    GPIO84 (pin #169) = Short to 3.3V (Vddio)

    Please can you confirm the above.

    As requested, I will also do the "test" using the ccxml target config and revert to you.

    Thanks

  • Hi Matthew

    I have proceeded by putting external wires on the GPIOs (mentioned above) and is now able to CONNECT for the first time since the error. 

    With the DSP in "check boot mode", I read the contents of the memory location 0x33FFF8 to 0x33FFFF as suggusted in your earlier post. As you/Vamsi had suspected, they are all 0x0000. Also, the message in the console suggests the device is locked. See below

    As the picure above doesn't show the complete console message, I have put a copy below.

    C28xx: GEL Output:
    ADC Calibration not complete, check if device is unlocked and recalibrate.C28xx: Flash Programmer: Warning: The configured device (TMS320F28335), does not match the detected device (). Flash Programming operations could be affected. Please consider modifying your target configuration file.
    C28xx: GEL Output:
    ADC Calibration not complete, check if device is unlocked and recalibrate.

    Questions:

    1. Why does it think that the DSP is not a TMS320F28335?
    2. If the DSP is locked, how do I unlock it?
    3. What caused the CSM memory location to be set to 0x0000 and more importantly how can I avoid this situation?
    4. Has the "ADC Calibration not complete" (see picture above) been caused by DSP not being in normal mode?
  • Sam,

    With regards to #1 and #4 this is both tied to the device being locked.  Both the PARTID and the ADC Calibration codes exist in secure memory, so if the device is locked CCS will read back all 0x0000 at both locations and give this error.  If you were intentionally using the CSM module this wouldn't effect the operation of the device in a system.

    For #2 since this was an unintentional program of the CSM we don't know the values that got programmed.  Because of this we have no way to unlock it.  The only solution would be to replace the device.

    For #3, this can be a result of an interruption of the erase or program process of the device.  This could be either from a power fault during the flash operation or XRSn/reset getting forced during the flash operation.  The flash API will take care of the watchdog/other ISRs so this should not be the reason this happened.  There could also be a potential if the JTAG connection were interrupted during the loading of flash from CCS.

    In terms of avoidance, assuming we don't know the cause of either a power fault or external XRSn driving low, i.e. there is potential high noise environment, JTAG stability; there are some keep outs we can use to safeguard this a bit more.

    As shown below the CSM passwords are in the main flash array, and part of Sector A.  If you have spare flash memory in your application I would avoid using Sector A, as this will prevent any interruption of the flash programmation from happening to Sector A.  This device also uses balanced sectors, as such Sector H can influence Sector A(and vice versa) so I would also limit my use of that sector if possible.

    If your memory usage is such that you need the full flash addresses, I would try and limit how often Sectors A and H need to be re-programmed(i.e. put static tables in there, etc).

    From a CCS implementation if you open the Flash Tools, you can actively deselect which sectors are erased when the code is loaded, if you have not used A/H you should deselect them so they they won't be mass erased on every load.

    Let me know if you have more questions/comments.

    Best,

    Matthew

  • Hi Matthew,

    Thanks for the update.

    This is the second time it has happened to me. i.e I have had another DSP on another PCB unintentionally locked during debugging with a JTAG emulator. It doesn't appear to be an emulaor issue as I had used a different emulator (same type though i.e XDS510LC) on this occassion and problem of locking out happened again. As mentioned earlier, there was no obviously noticeable interruption of power / JTAG connection that may have lead to the DSP lock out. I am concerned that without knowing the root cause, this will happen again.

    Also, the orignal reason I have been debugging this DSP is that our flash based control software returns an erratic value for fundamental frequency estimation (using zero crossing detection method) on this DSP only. The same control software on other DSPs works as expected. Some questions.

    1. If the erratic frequency issue happens again, what h/w or s/w tools do you suggest for testing DSPs (flash integrity checks?)
    2. Is it possible to return this locked out DSP to TI for further investigation?

  • Sam,

    1)Can you let me know the other DSPs that things work correctly on?  I'd like to compare the modules against the ones on this device to make sure there isn't some errata that effects one and not the other.

    2)You can return the device following the flow outlined here https://www.ti.com/support-quality/additional-information/customer-returns.html , however for a locked device there is not much we can do in terms of functional testing.  The analysis can certainly look for any opens/shorts that may be an indicator of the fault or physical damage.

    3) In terms of debug you can either use CCS or Uniflash to scan out the flash contents to make sure they match to a golden source/file.  This would tell us if the flash contents are somehow different than intended.

    Is this issue happen on all F2833x devices or just a subset?  Is the issue present at time 0, or do the bad devices work correctly for some time, then fail?  Any other correlating issues like temperature or supply level that you know of? 

    Can you comment on the CPU clock rate in your system of the F2833x as well as the nominal supply levels?

    Lastly, can you let me know the top side markings of some failing devices, if not 100% fail rate also some working devices?

    Best,

    Matthew

  • Hi Matthew,

    Thanks for the update.

    Please see below response.

    1)Can you let me know the other DSPs that things work correctly on? I'd like to compare the modules against the ones on this device to make sure there isn't some errata that effects one and not the other.
    Ans: The other DSPs are of the same type i.e TMS320F28335. What specific details are you after? What specific modules can you compare and how?
    2)You can return the device following the flow outlined here www.ti.com/.../customer-returns.html , however for a locked device there is not much we can do in terms of functional testing. The analysis can certainly look for any opens/shorts that may be an indicator of the fault or physical damage.
    Ans: Will get back to you.
    3) In terms of debug you can either use CCS or Uniflash to scan out the flash contents to make sure they match to a golden source/file. This would tell us if the flash contents are somehow different than intended.
    Ans: Have you got any written instructions on how to do this?

    Is this issue happen on all F2833x devices or just a subset? Is the issue present at time 0, or do the bad devices work correctly for some time, then fail? Any other correlating issues like temperature or supply level that you know of?
    Ans: Has happened on one TMS320F28335 DSP so far. Is present from Time 0 until power down. Temperature and supply rails are consistent as far as I can measure. Replacing the suspect DSP (the one that locked out and had the frequency issue) with another DSP of the same type on the same PCB solves the problem. i.e the new DSP on the same PCB reports the correct Frequency.

    Can you comment on the CPU clock rate in your system of the F2833x as well as the nominal supply levels?
    Ans: Is clocked at 150MHz, Nominal 3V3 = ~3.305V

    Lastly, can you let me know the top side markings of some failing devices, if not 100% fail rate also some working devices?
    Ans: Will get back to you.

  • Sam,

    Thanks for the clarification, I didn't know if you meant other C2000 part numbers or just different devices with the same PN, so this clears that up. 

    If you are seeing a general misbehavior that is unique to a single device(in addition to the flash issue), then there may be something more detectable if the device is returned to us for failure analysis.  We will test the device using the same test program as when it was manufactured, and see if there is any new abnormality that was not present when new.

    I think I got  confused with my #3 above, if there is a device that is still unlocked and is not performing correctly we can do this, but if the only unit that was bad is also locked then this is not possible.  Let me know if my understanding is correct.

    Will wait for your clarification but I think it makes sense to go ahead and follow the web link for returning a device to TI for out of spec behavior/Failure Analysis.

    Best,

    Matthew

  • Thanks for the response. About #3, I do not have another failed and unlocked unit at the moment. But that is not saying it won't happen in the future. If it does, I would like to be able read the Flash contents of both the failed unit and a golden sample and compare. Therefore, please can you share any instructions on how to do this via UniFlash?

  • Sam,

    There are 2 methods in Uniflash.

    #1 you can specify the flash load file, but use the "verify" button to check that the contents are what you expect:

    #2

    If you click on the memory browser tab, you can view and then export a region of memory.  You would want to do this on a known good device so you have a "golden" image to compare to.  This step could be determined based on #1's result so you can see what addresses are not matching.

    Best,

    Matthew

  • Thanks for the instructions.

    My current version of UniFlash v3.4.1 doesn't seem to have the Memory option (mentioned above).

    If I update UniFlash to the latest v7.2.0, it fails to recognize the JTAG XDS510LC USB emulator I have.

    Which UniFlash version has both of the above?

  • Sam,

    I'm looking into this, needing some input from some other engineers in our tools team for the support breakout.  Please give me a couple of days to get this info.

    Best,

    Matthew

  • Sam,

    I believe that Uniflash V4.x should work for both debugger support and the memory save we want.

    https://software-dl.ti.com/ccs/esd/uniflash/docs/release_archive.html#uniflash-v4-releases

    If this doesn't work, we can use CCS(whatever version you have) to accomplish the same thing, just a few more mouse clicks!

    Let me know.

    Best,

    Matthew

  • Thanks for the update. I will give Uniflash V4.x a try and update you.

  • Doesn't look like Uniflash v4.x supports JTAG XDS510LC USB either.

  • Sam,

    I mis-takenly saw the XDS110, and confused that with the 510LC.  You will need to use Code Composer, and then you can View->memory with the flash address you want, then you can save this off.

    Can you confirm the version of CCS you are using?  If you have V3.3 or older it may be in a slightly different menu option than above.

    Best,

    Matthew