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.

MSP-EXP432E401Y: How to deal with "Error-615"

Part Number: MSP-EXP432E401Y
Other Parts Discussed in Thread: MSP432E401Y

Hi experts,

My customer is using MSP-EXP432E401Y, and suddenly the following error occurs and the software cannot be written.

Q: Could you please tell me how to solve this problem?

They tried the following, but it did not solve the problem.

  1. Check if the TMS and TCK jumpers are in place on LaunchPad. ......Recheck result: -615
    →Refer to "Incorrect SWD header".
  2. Lower TLCK from Target Configration. ......Recheck result: -615
    →The "The JTAG TCLK Frequency" in Target Configration is lowered.
  3. Check if JTAG Mode is set to "SWD Mode" in Target Configuration. ......Recheck result: -615
    →Change JTAG/SWD/cJTAG Mode to "SWD Mode- ~~TDO" or "SWD Mode- ~~UART" in Target Configration.
  4. Replace the USB cable. ......Recheck result: -615
  5. Use a different sample code to check the writing. ......Recheck result: -615
    →Use "buttonled".
  6. Set the device to the factory default. ......Recheck result: -615
    →Refer to "Using SimpleLink MSP432E4 microcontrollers over the JTAG interface (Rev. A)"."5.3 Executing Unlock Sequence" and "6.2 JTAG Not Working After Software Was Loaded".

The F/W (user program created by the customer) that they wrote before seems to be working, and they can input commands and display data from the UART via USB on the XDS110.
The same phenomenon occurs when they connects this evaluation board to another PC for debugging.

Currently, I'm asking for confirmation that they can use an external emulator and to share the F/W that they originally wrote. I would appreciate it if you could tell me if there is another way to solve this problem.

Best regards,
O.H

  • Hello,

    Currently, I'm asking for confirmation that they can use an external emulator and to share the F/W that they originally wrote.

    It sounds like an emulator issue, so trying with an emulator on another LaunchPad or an external emulator would be a good test to determine if it's an issue with the target device or not. Hopefully their code did not disable the JTAG pins, but if you can program the target device with another emulator, then the code is not the issue.

  • Hello James Evans,

    Sorry for the late reply.

    We are currently lending an external emulator to a customer to see if he can connect to the MSP432 on the target LaunchPad. We will share the results as soon as we know.

    Best regards,
    O.H

  • Sounds good. Thanks for the update.

  • Hello James Evans,

    The customer used an external emulator (XDS110, 200) and was unable to connect to the device. (They only have one LaunchPad, so they did not check with another LaunchPad onboard emulator.)

    JTAG connection is not possible and the last application code I wrote before it stopped working is working via debug serial. This leads me to believe that the JTAG area of the board is damaged.

    Alternatively, there may be a problem with the code because the code I wrote before is still working even though I have implemented "Set the device to the factory default".

    Best regards,
    O.H

  • It definitely sounds like there's an issue with the device, so having another device (or several devices) would help narrow down the root cause here.

    JTAG connection is not possible and the last application code I wrote before it stopped working is working via debug serial. This leads me to believe that the JTAG area of the board is damaged.

    It's possible. Table 4 in the Using SimpleLink MSP432E4 microcontrollers over the JTAG interface app note lists the possible causes excluding physical or ESD damage. It may be good to carefully review their firmware to see if any of these scenarios exist.

    Alternatively, there may be a problem with the code because the code I wrote before is still working even though I have implemented "Set the device to the factory default".

    If the unlock sequence was performed correctly, the device should be unlocked and accessible over JTAG.

  • Hello James Evans,

    Thanks for the reply. The customer will be sending us the application code and evaluation board, so we will check it out. I will contact you again as soon as I know the result.

    Best regards,
    O.H

  • Thanks for the update!

  • Hello James Evans,

    We checked using the customer's LaunchPad(hereafter referred to as "A") and our own LaunchPad(hereafter referred to as "B"). The result is that the problem seems to be on the MSP432E401Y side of the customer's LaunchPad(A).

    • A's XDS110 connects to A's MSP432E4 ... failure
    • A's XDS110 connects to B's MSP432E4 ... Success
    • B's XDS110 connects to B's MSP432E4... Success
    • B's XDS110 connects to A's MSP432E4... Failure
    • External XDS110 connects to A's MSP432E4...Failure
    • External XDS200 connects to A's MSP432E4...Failure
      →I have attached the log contents when I used external XDS110 and XDS200.
    • External XDS110 connects to B's MSP432E4...Success
    • External XDS200 connects to B's MSP432E4...Success

    I also checked the unlock sequence

    • I ran it against A, but the device did not go to factory state.
      →I am attaching the log contents when I used external XDS110 and XDS200.
    • I ran it against B, and the device is now in the factory state.
      →I wrote a program to toggle the LED, and confirmed that the LED does not toggle after the unlock sequence is executed.

    Can I assume that the MSP432E401Y is faulty from the above?

    Best regards,
    O.H

    [Start: Texas Instruments XDS110 USB Debug Probe_0]
    
    Execute the command:
    
    %ccs_base%/common/uscif/dbgjtag -f %boarddatafile% -rv -o -S integrity
    
    [Result]
    
    
    -----[Print the board config pathname(s)]------------------------------------
    
    C:\Users\12582\AppData\Local\TEXASI~1\CCS\
        ccs1010\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 'Jan 31 2021'.
    The library build time was '20:08:09'.
    The library package version is '9.3.0.00042'.
    The library component version is '35.35.0.0'.
    The controller does not use a programmable FPGA.
    
    An error occurred while hard opening the controller.
    
    -----[An error has occurred and this utility has aborted]--------------------
    
    This error is generated by TI's USCIF driver or utilities.
    
    The value is '-615' (0xfffffd99).
    The title is 'SC_ERR_SWD_PROTOCOL'.
    
    The explanation is:
    The target failed to see a correctly formatted SWD header. The 
    connection to the target may be unreliable. Try lowering the 
    TCLK setting before trying again.
    
    [End: Texas Instruments XDS110 USB Debug Probe_0]
    
    [Start: Texas Instruments XDS2xx USB Debug Probe_0]
    
    Execute the command:
    
    %ccs_base%/common/uscif/dbgjtag -f %boarddatafile% -rv -o -S integrity
    
    [Result]
    
    
    -----[Print the board config pathname(s)]------------------------------------
    
    C:\Users\12582\AppData\Local\TEXASI~1\CCS\
        ccs1010\0\0\BrdDat\testBoard.dat
    
    -----[Print the reset-command software log-file]-----------------------------
    
    This utility has selected a 560/2xx-class product.
    This utility will load the program 'xds2xxu.out'.
    
    An error occurred while soft opening the controller.
    
    -----[An error has occurred and this utility has aborted]--------------------
    
    This error is generated by TI's USCIF driver or utilities.
    
    The value is '-300' (0xfffffed4).
    The title is 'SC_ERR_PLL_BAD_TCLK_PROGRAM'.
    
    The explanation is:
    The requested TCLK PLL programming option is invalid.
    The utility or debugger has requested a selection of
    the JTAG PLL frequency or clock source that is invalid.
    The value of USCIF.TCLK_PROGRAM is probably bad.
    
    [End: Texas Instruments XDS2xx USB Debug Probe_0]

  • Hello,

    We checked using the customer's LaunchPad(hereafter referred to as "A") and our own LaunchPad(hereafter referred to as "B"). The result is that the problem seems to be on the MSP432E401Y side of the customer's LaunchPad(A).

    Nice work. I appreciate the thorough testing! I think your results clearly demonstrate there is an issue with A's MSP432E4.

    I also checked the unlock sequence

    That's great. I'm sorry to see A's MSP432E4 can't be unlocked. A normal device should be unlocked like B's MSP432E4. The only thing left to check would be the steps on page 18 in the Using SimpleLink MSP432E4 microcontrollers over the JTAG interface app note to see if the root cause is a power issue on the LaunchPad. But, it may not be worth the time investigating further.

    Can I assume that the MSP432E401Y is faulty from the above?

    I think that's clear. To be absolutely sure and if you have the equipment, you could replace A's MSP432E4 with a new one. There could be some strange hardware issue on the LaunchPad. However, it may be easier to just purchase a new LaunchPad from the TI Store.

  • Hello James Evans,

    I appreciate your perspective.

    That's great. I'm sorry to see A's MSP432E4 can't be unlocked. A normal device should be unlocked like B's MSP432E4. The only thing left to check would be the steps on page 18 in the Using SimpleLink MSP432E4 microcontrollers over the JTAG interface app note to see if the root cause is a power issue on the LaunchPad. But, it may not be worth the time investigating further.

    In the meantime, I have checked the power supply and it is stable, so I will assume that the chip is faulty and move forward.

    Best regards,
    O.H

  • Thanks for the update. Nice work!