• State TI Thinks Resolved
  • Locked Locked
  • Replies 11 replies
  • Answers 1 answer
  • Subscribers 32 subscribers
  • Views 3535 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

TM4C123GH6PZ: CORTEX_M4_0: Can't Run Target CPU: (Error -1268 @ 0x1090001) Device is locked up in Hard Fault or in NMI. CORTEX_M4_0: Flash Programmer: Error while writing to Flash memory CORTEX_M4_0: File Loader: Verification failed: Values at address

Murali Prasad
Prodigy 225 points
Part Number: TM4C123GH6PZ
Other Parts Discussed in Thread: UNIFLASH, EK-TM4C123GXL

Hi,

We are using TM4C123GH6PZ-100 pin LQFP package IC, when we try to put the project in debug mode we are getting Error as below.

CORTEX_M4_0: GEL Output:
Memory Map Initialization Complete
CORTEX_M4_0: Can't Run Target CPU: (Error -1268 @ 0x1090001) Device is locked up in Hard Fault or in NMI. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 6.0.504.1)
CORTEX_M4_0: Flash Programmer: Error while writing to Flash memory
CORTEX_M4_0: File Loader: Verification failed: Values at address 0x00000000 do not match Please verify target memory and memory map.
CORTEX_M4_0: GEL: File: C:\Users\Admin\Desktop\C_32bit\C\Debug\C.out: a data verification error occurred, file load failed.

Ti distributor had suggested to change the IC and check we tried the same and we got same above error in the new board also.

We tried flashing .hex  or .out file using uniflash, it also shown same error.   we tried loading the example code .out file and the above error is still persist.

Device is not entering to debug state ,To identify the cause of fault and using the NVIC fault register.

Kindly guide us in resolving the above error.

 

Thanks in advance.

 

Regards,

Murali Prasad

 

  • 0
    TI__Guru 72500 points
    Is this device on a custom board? Have you verified that the hardware is correct? Check power, the RST signal and the JTAG signals. What type of scan controller are you using?

    Do you have an EK-TM4C123GXL launchpad? If so, does it work with that PC and USB port?
  • 0 in reply to Bob Crosby
    Prodigy 225 points
    HI Bob,

    Yes it is custom board, we have verified the hardware and checked the power,RST signals and JTAG Debugger.
    JTAG debugger is working fine.

    currently we don't have EK-TM4C123GXL launchpad.

    Thanks & Regards,
    Murali Prasad
  • 0 in reply to Murali Prasad
    Guru 56093 points
    Hi Murali,

    Perhaps the external XTAL or MOSC is failing? Removal of XTAL so MCU is forced to use PIOSC may reveal an underlying clock issue. That assumes CCS debug you first do manual Reset core after NMI and have run JTAG test and passed no errors.
  • 0 in reply to Murali Prasad
    TI__Guru 72500 points
    This still looks like a hardware issue to me. How did you conclude that the JTAG debugger is working fine? What type of scan controller are you using? Can you share the schematic showing the connections between the TM4C123 and the JTAG connector?
  • 0 in reply to Bob Crosby
    Prodigy 225 points

    Hi Bob,

    PFA Jtag connection test report and Schematic b/w TM4C123 and JTAG connector.

    If you find any issue Kindly let us know.

    [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\Admin\AppData\Local\TEXASI~1\CCS\
    ti\2\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 'Dec 9 2016'.
    The library build time was '13:48:53'.
    The library package version is '6.0.504.1'.
    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.

    [End: Texas Instruments XDS110 USB Debug Probe_0]

    Thanks & Regards,

    Murali Prasad

  • 0 in reply to Murali Prasad
    TI__Guru 72500 points
    Are the TRST, EMU0 or EMU1 pins of the JTAG connector connected to the TM4C? They should not be. What is the level on the RST pin (pin 63)? It should be high.
  • 0 in reply to Bob Crosby
    Guru 56093 points

    Hi Bob,

    Bob Crosby said:
    Are the TRST

    Did you mean to infer the ICDI/JTAG emulator can not HW reset the MCU via TRST connection? Our PCB has the same TRST on TM4C1294 with 470 ohm in series to MCU reset pin. Seemingly the emulator does not issue hardware reset to MCU unless instructed by CCS debug.

  • 0 in reply to Genatco
    TI__Guru 72500 points
    It is not the intent of the nTRST pin on the JTAG scan controller to reset the MCU. The intent was to put the debug logic into "Test Logic Reset" state. (Hence the T in the signal name nTRST.) The TM4C devices do not have an external nTRST pin like some other microcontrollers. The scan controllers reset the JTAG logic using a sequence of TCK and TMS. The XDS110 has another signal, nRESET, which is intended to be a device reset. Not all JTAG connectors support this signal. Code composer can reset the device using the JTAG logic in the part and just TCK, TMS and TDI.

    The downside I see of connecting nTRST to the nRST pin of the device is that you will not be able to connect a debugger to a part that is "not responding" and see the current state of the part. The debugger will end up resetting the part when it tries to initialize the JTAG port. My concern here was that it was not shown on the schematic and the pulldown on nTRST could adversely affect the level on nRST if connected.
  • 0 in reply to Bob Crosby
    Prodigy 225 points

    @Bob

    Are the TRST, EMU0 or EMU1 pins of the JTAG connector connected to the TM4C?

    These pins are not connected to MCU.

    What is the level on the RST pin (pin 63)?

    After power on reset the signal is high.

    nTRST pin of debugger is not connected to MCU nRST pin.

    we have assembled  MCU,Reset + debugger and power supply components only on the board without other component apart from these there isn't any component to cause hardware issue.

    PFA reset circuit for your reference.

    Thanks & Regards,

    Murali Prasad

  • 0 in reply to Murali Prasad
    TI__Guru 72500 points
    I think I see the issue. You are using a 20MHz external crystal. All the examples are based on a 16MHz crystal. The crystal frequency for the serial bootloader can be changed on line 63 of the file "bl-config.h", but unfortunately 20MHz is not one of the crystal frequencies supported in this example. (See bl_crystal.h) Can you use a 16MHz crystal?
  • 0 in reply to Bob Crosby
    Guru 56093 points

    Bob Crosby said:
    The downside I see of connecting nTRST to the nRST pin of the device is that you will not be able to connect a debugger to a part that is "not responding" and see the current state of the part. The debugger will end up resetting the part when it tries to initialize the JTAG port

    Ok my JTAG pin 10 is reset into MCU same as EVM with external ICDI pushes reset to MCU. Simply uncheck debug box to disable reset device on target connect and program load. I leave those boxes unchecked any way since resetting target often end up causing immediate RUN mode NMI faults upon entry or after one or more CCS edits on the same connection instance.