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.

CCS/TM4C123FH6PM: Problems with establishing connection to target with J-Link Lite Probe

Part Number: TM4C123FH6PM

Tool/software: Code Composer Studio

Hello Everyone,

After flashing a program that went to Fault ISR, I no longer can connect to the chip I have.(TM4C123FH6PM)
I get flashing Red Light on the probe and you may find the log files attached.
I am not too familiar with this probe so I am not sure why I can't connect.
I used J-Flash and Innate tools from Code Composer Studio and behaviour seems to be the same.

T3228 208:049.734   SEGGER J-Link V6.64 Log File
T3228 208:049.811   DLL Compiled: Mar 13 2020 15:55:42
T3228 208:049.838   Logging started @ 2020-03-18 13:21
T3228 208:051.593 JLINK_SelectUSB(Port = 0)
T3228 208:052.724 - 1.154ms returns 0x00
T3228 208:052.803 JLINK_OpenEx(...)
T3228 208:056.096   Firmware: J-Link Lite-Cortex-M V8 compiled Sep 15 2016 12:05:01
T3228 208:058.369   Hardware: V8.00
T3228 208:058.415   S/N: 518109770
T3228 208:058.441   OEM: SEGGER
T3228 208:058.469   Feature(s): GDB
T3228 208:059.773   TELNET listener socket opened on port 19021
T3228 208:059.960   WEBSRV Starting webserver
T3228 208:060.119   WEBSRV Webserver running on local port 19080
T3228 208:060.161 - 7.369ms returns "O.K."
T3228 208:060.199 JLINK_GetFirmwareString(...)
T3228 208:063.770 - 3.577ms
T3228 208:065.716 JLINK_TIF_Select(JLINKARM_TIF_SWD)
T3228 208:066.404 - 0.696ms returns 0x00
T3228 208:066.426 JLINK_CORE_Select(100663551)
T3228 208:066.434 - 0.010ms
T3228 208:066.453 JLINK_ExecCommand("Device = Cortex-M0", ...). 
T3228 208:071.465   Device "CORTEX-M0" selected.
T3228 208:073.301 - 6.847ms returns 0x00
T3228 208:073.325 JLINK_ExecCommand("ExcludeFlashCacheRange 0x0-0xFFFFFFFF", ...). 
T3228 208:073.338 - 0.006ms returns 0x00
T3228 208:073.349 JLINK_GetAvailableLicense()
T3228 208:077.120 - 3.779ms returns 0x01
T3228 208:077.143 JLINK_SetEndian(ARM_ENDIAN_LITTLE)
T3228 208:077.150 - 0.009ms returns 0x00
T3228 208:077.158 JLINK_SetSpeed(4000)
T3228 208:077.294 - 0.143ms
T3228 208:077.309 JLINK_GetSpeed()
T3228 208:077.315 - 0.009ms returns 0x7D0
T3228 208:079.102 JLINK_GetHWStatus(...)
T3228 208:079.342 - 0.248ms returns 0x00
T3228 208:080.996 JLINK_Connect()
T3228 208:655.913 - 574.944ms returns 0xFFFFFFFF
T3228 208:668.123 JLINK_Close()
T3228 208:672.198 - 4.101ms
T3228 208:672.229   
T3228 208:672.238   Closed
Connecting ...
 - Connecting via USB to J-Link device 0
 - J-Link firmware: J-Link Lite-Cortex-M V8 compiled Sep 15 2016 12:05:01
 - Device "CORTEX-M0" selected.
 - Target interface speed: 2000 kHz (Fixed)
 - VTarget = 3.287V
 - ERROR: Failed to connect.
Could not establish a connection to target.

Best Regards,
Tuna Bicim

  • Have you tried the steps for recovering a locked microcontroller? Here is a thread that discusses doing that with JLINK.

    https://e2e.ti.com/support/microcontrollers/other/f/908/t/589879?TM4C123BH6ZRB-Question-on-recovering-a-locked-microcontroller

  • Hello Bob,

    The stuff posted on that link didn't help.

    I have a ek board but jumping the jtag pins is really hard because of the small header on my board. (10 pin arm header)

    Do you have any other suggestions?

    Best,

    Tuna Bicim 

  • Greetings,

    If I may:

    Tuna Bicim said:
    jumping the jtag pins is really hard because of the small header on my board. (10 pin arm header)

    As that 10 pin - 0.050" pitch header is (exactly) that used by our firm - you should know that there are a variety of "20 pin, 0.1" pitch to 10 pin, 0.050" pitch" connection cables (w/proper receptacles each end) commercially available.   It is assumed that the J-Link Lite employs the 20 pin, 0.1" pin pitch (male header) - as does the "standard" J-Link.

  • I am confused by your comment. The post highlighted as the solution from Chester Gillon in the thread I referenced used a J-Link controller. Perhaps the J-Link Lite probe does not support the scripts. You would need to ask Seggar that question.

    Have you tried using Code Composer and your J-Link Lite probe to unlock the device? I do not have the J-Link lite probe so I cannot verify for you. Here is a picture of using an XDS200:

      

  • I'll try that solution with the proposed "bitbanged" switch sequence. 

    I tried the command on the SWD switch but didn't continue because there wasn't a command for the JTAG part I'll try to run the script.

    How do you get to the On-Chip Flash tab. I checked views on CCS but didn't find it. 

    Best,

    Tuna 

  • From the top menu select "Tools" -> "On-Chip Flash".

  • Hello Bob,

    I tried the script, didn't work. I also jumped from ICDI on my ek board, also didn't work.

    I'll just replace the chip because this is proving to be real time sink. 

    Also I don't have that option under tools for some reason.

    Best,

    Tuna 

  • Failed Connection Greetings,

    Feel your pain.- yet even after - especially after - you invest the time, cost, effort to replace the MCU ... you must critically review, discover & correct the source program which (appeared) to have "Caused your lock-out issue" prior to, "Reloading that program!"

    Failure to do so will likely result in your (unwanted) entry to a, "Return to Lock-Out Loop!"

    Usual suspects for such Lock-Out include:

    • inadvertent and/or deliberate "Re-Purposing of (any) of the 4 JTAG signal pins"
    • Disagreement between the (actual) value of the main oscillator's xtal frequency & your declaration w/in "SysCtlClockSet()"

    Your attempted "Reload" should begin w/one of the most basic, vendor supplied, example programs.

  • Hello cb1,

    Yes, I already corrected the program. It was a peripheral configuration issue. 

    I don't use the jtag pins for anything else so I am not even sure why they got locked.

    My guess is the chip goes into fault isr way too fast before anything can be done.

    As a preventive measure after configuring the clock or even before that I think I will put a delay on the debug mode so that I can have enough time before the bad config is done to connect to the processor. That was suggested on other posts. 

    Thanks,

    Tuna 

  • Glad to learn that you have reached that level of recognition.   (i.e. Corrected the program prior to "Attempted" Re-Load.   Few things are as frustrating as, "Yanking the MCU - & instantly (& repeatedly) KILLING ITS REPLACEMENT - AGAIN!)

    Do search (and find) "jtag-gpio.c" (or similar) which provides an excellent mechanism for, "Re-Purposed JTAG pins to be recovered - almost painlessly."

    In our experience:

    • marginal power supply
    • simply allowing the JTAG pins to float
    • inadequate VDD, VDDC pcb routing and/or trace width

    often contribute to the issue you've noted...   Careful, thoughtful (& practiced) Design does "wonders" to prevent issues!