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.

TMS320F28027F: Micro stuck in a reset cycle

Part Number: TMS320F28027F
Other Parts Discussed in Thread: UNIFLASH

Ive got a 28027 that is stuck in a periodic reset cycle of a 13ms out of reset and 58us in reset and i am unable to reprogram it. I am also unsure as to the route cause of the micro getting into this state. It was running fine and then after an attempt to reprogram it its ended up in this state. we are using an XDS110 Debugger to program and this can happen using either Code Composer Studio and Uniflash as weve seen this a few times and our only solution so far is to change the micro.

On the board there is an external Watchdog, the reset pin of this has been lifted to ensure that this is not the route cause of the issue and the same behaviour continues. The scope traces below are taken from the nRST pin of the micro.

The software being loaded at the time has been ran for a number of weeks with 0 issues and was unchanged so hopefully this isnt the issue.

Any advice of the route cause and a recovery would be really appreciated.

Chris

  • Chris,

                  The watchdog is timing out and resetting the device. It is possible that your attempt to reprogram the device was unsuccessful and the flash ended up in an erased (or corrupted) state. Are you able to connect to the device via CCS? Can you share privately the schematics of the circuitry connected to the -XRS pin ? You may find this post interesting: https://e2e.ti.com/support/microcontrollers/c2000/f/c2000-microcontrollers-forum/937326/ccs-tms320f28069-do-not-use-wait-mode 

  • Hareesh,

    Thanks for taking the time to reply, if by connect you mean verify the connection in CCS then ive attempted it and it reports issues - See log below.

    -----[Print the reset-command software log-file]-----------------------------

    This utility has selected a 100- or 510-class product.
    This utility will load the adapter 'jioxds110.dll'.
    The library build date was 'Aug 26 2019'.
    The library build time was '13:34:49'.
    The library package version is '8.3.0.00003'.
    The library component version is '35.35.0.0'.
    The controller does not use a programmable FPGA.
    The controller has a version number of '5' (0x00000005).
    The controller has an insertion length of '0' (0x00000000).
    This utility will attempt to reset the controller.
    This utility has successfully reset the controller.

    -----[Print the reset-command hardware log-file]-----------------------------

    The scan-path will be reset by toggling the JTAG TRST signal.
    The controller is the XDS110 with USB interface.
    The link from controller to target is direct (without cable).
    The software is configured for XDS110 features.
    The controller cannot monitor the value on the EMU[0] pin.
    The controller cannot monitor the value on the EMU[1] pin.
    The controller cannot control the timing on output pins.
    The controller cannot control the timing on input pins.
    The scan-path link-delay has been set to exactly '0' (0x0000).

    -----[An error has occurred and this utility has aborted]--------------------

    This error is generated by TI's USCIF driver or utilities.

    The value is '-233' (0xffffff17).
    The title is 'SC_ERR_PATH_BROKEN'.

    The explanation is:
    The JTAG IR and DR scan-paths cannot circulate bits, they may be broken.
    An attempt to scan the JTAG scan-path has failed.
    The target's JTAG scan-path appears to be broken
    with a stuck-at-ones or stuck-at-zero fault.

    Ive looked at the post you linked and weve tried the same thing and previously this has worked with one of the times this has happened, but weve continued to try a number of times and its not worked since sadly. (Its worked once).

    Regarding the schematics ill speak with my manager and get these organised to be shared.

  • I wonder if the device has become inadvertently locked (due to corrupted password locations). This can happen if the programming process is interrupted (blackout/brownout or the device being current-starved during programming). Are you able to put the device in "Wait" mode? Please read sections 9.1.8 and 9.1.9 of https://www.ti.com/lit/gpn/tms320f28027  very carefully.

    You may find this doc useful: https://www.ti.com/lit/pdf/spracf0 

  • Putting the micro in wait mode has given us a different error but didnt allow for us to program the micro. But i was able to verify the connection with the micro within CCS. See log below.

    [Start]

    Execute the command:

    %ccs_base%/common/uscif/dbgjtag -f %boarddatafile% -rv -o -S integrity

    [Result]


    -----[Print the board config pathname(s)]------------------------------------

    C:\Users\CHRISG~1\AppData\Local\TEXASI~1\
    CCS\ccs920\0\0\BrdDat\testBoard.dat

    -----[Print the reset-command software log-file]-----------------------------

    This utility has selected a 100- or 510-class product.
    This utility will load the adapter 'jioxds110.dll'.
    The library build date was 'Aug 26 2019'.
    The library build time was '13:34:49'.
    The library package version is '8.3.0.00003'.
    The library component version is '35.35.0.0'.
    The controller does not use a programmable FPGA.
    The controller has a version number of '5' (0x00000005).
    The controller has an insertion length of '0' (0x00000000).
    This utility will attempt to reset the controller.
    This utility has successfully reset the controller.

    -----[Print the reset-command hardware log-file]-----------------------------

    The scan-path will be reset by toggling the JTAG TRST signal.
    The controller is the XDS110 with USB interface.
    The link from controller to target is direct (without cable).
    The software is configured for XDS110 features.
    The controller cannot monitor the value on the EMU[0] pin.
    The controller cannot monitor the value on the EMU[1] pin.
    The controller cannot control the timing on output pins.
    The controller cannot control the timing on input pins.
    The scan-path link-delay has been set to exactly '0' (0x0000).

    -----[Perform the Integrity scan-test on the JTAG IR]------------------------

    This test will use blocks of 64 32-bit words.
    This test will be applied just once.

    Do a test using 0xFFFFFFFF.
    Scan tests: 1, skipped: 0, failed: 0
    Do a test using 0x00000000.
    Scan tests: 2, skipped: 0, failed: 0
    Do a test using 0xFE03E0E2.
    Scan tests: 3, skipped: 0, failed: 0
    Do a test using 0x01FC1F1D.
    Scan tests: 4, skipped: 0, failed: 0
    Do a test using 0x5533CCAA.
    Scan tests: 5, skipped: 0, failed: 0
    Do a test using 0xAACC3355.
    Scan tests: 6, skipped: 0, failed: 0
    All of the values were scanned correctly.

    The JTAG IR Integrity scan-test has succeeded.

    -----[Perform the Integrity scan-test on the JTAG DR]------------------------

    This test will use blocks of 64 32-bit words.
    This test will be applied just once.

    Do a test using 0xFFFFFFFF.
    Scan tests: 1, skipped: 0, failed: 0
    Do a test using 0x00000000.
    Scan tests: 2, skipped: 0, failed: 0
    Do a test using 0xFE03E0E2.
    Scan tests: 3, skipped: 0, failed: 0
    Do a test using 0x01FC1F1D.
    Scan tests: 4, skipped: 0, failed: 0
    Do a test using 0x5533CCAA.
    Scan tests: 5, skipped: 0, failed: 0
    Do a test using 0xAACC3355.
    Scan tests: 6, skipped: 0, failed: 0
    All of the values were scanned correctly.

    The JTAG DR Integrity scan-test has succeeded.

    We are now getting the below errors within CCS and Uniflash

    06/05/2021 17:30:30] [ERROR] C28xx: Flash Programmer: Device is locked or not connected. Operation cancelled.
    [06/05/2021 17:30:30] [ERROR] C28xx: File Loader: Memory write failed: Unknown error

    Ive tried programming and erasing the micro once in wait mode and it didnt allow for either sadly.

  • Since you are able to connect to the device via CCS, there is no H/W issue per se. It is likely the password locations got corrupted and the device became inadvertently locked. Unfortunately, there is no way to recover such a locked device. If the Erase/Program operation is not interrupted and completes successfully, such locking should not happen. Please investigate the root-cause for such accidental locking.

  • The micro is powered from 2 rails orred together, we believe when these supplies are switching over there is a lot of ripple which may have happened during programming and caused some form of damage or corruption in some way. Thakns for your help