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.

TM4C129ENCPDT: JTAG UNLOCK

Part Number: TM4C129ENCPDT
Other Parts Discussed in Thread: SEGGER

Hi Team,

 

I can perform JTAG Unlock successfully by using the LM Flash SW and Debug HW card

That was a part of old CORTEX M3 Evaluation board (attached).

 OLD Debug HW card.docx

I need the following from you:

 

1.       Are there any other HW cards or products that can link to the LM Flash SW and

Perform JTAG Unlock?

2.       Send me documentation about the LM Flash regarding HW issues..

There are more JTAG tools that are in use:

 

1.       JLINK.

 

2.       MSP-PRGS430.

 

3.       FlashPro430.

 

I like to know if they are capable to take charge over the TM4C129 and to

Perform JTAG Unlock by the LM Flash programmer SW or any other SW?

 

Pictures of the JTAG tools attached.

JTAG tools.docx

I Need to find existing HW tool that supports the JTAG Unlock..

Thanks,

Shlomi

 

 

 

 

  • See section 5.3 starting on page 20 of this document:
    www.ti.com/.../spma075.pdf
  • Hi Bob,

    I see that JLINK Tool can link to TM4C129 .

    Does LM Flash can be connected to JLINK and to perform

    JTAG Unlock?

    Thanks,

    Shlomi

     

  • You may note that the J-Link - operated under (maker) Segger's software - employs an, "Unlock Mechanism" as well.    And - it has been our experience - that use of the J-Link - 'escapes & avoids' most of the 'unpleasantness' caused by (always unwanted - yet largely recurring) JTAG Lockout...

  • I can't get you…

     

    LM Flash can link via JLINK and perform JTAG UNLOCK?

  • I've no experience - and no desire - to employ a 'vendor specific' (LM Flash, here) 'solution.'      (FAR too limited... there are MANY ARM MCUs from many vendors...)

    As stated - 'Segger's J-Link (and their provided software) ARE ABLE to unlock (many) ARM MCUs.'      

    Might you 'read again?'      Then - 'what specifically',   'Can't you get?'

  • Hi TI Team,

    Here again I have a problem with the JTAG Unlock.
    There are four cards that were tested over the JTAG Unlock JIG.

    The first card succeeded with the process: The Flash and the MAC Address are cleared and the JTAG took control over and can burn a new SW.

    The Other 3 cards – The Flash was erased and the MAC address is cleared but the JTAG connecting to the card is failed, the cards are stuck in a state that the Flash is erased but it is impossible to burn new SW via JTAG…

    Thanks,
    Shlomi
  • Shlomi Yehezkia said:
    The Other 3 cards – The Flash was erased and the MAC address is cleared but the JTAG connecting to the card is failed, the cards are stuck in a state that the Flash is erased but it is impossible to burn new SW via JTAG…

    Assume you custom PCB: Ring out JTAG header pins leading into MCU pin? Custom PCB have 10Rk pull up to +3v3 for SWDIO/SWCLK pins near header? 

  • This is the data that is received from JTAG that indicates about the

    None identification.

    jtag-unlock.txt
    Info: Device "TM4C129ENCPDT" selected (1024 KB flash, 256 KB RAM).
    S/N: 158009270 OEM: IAR 
    VTarget = 3.351V
    Info: TotalIRLen = 4, IRPrint = 0x01
    
    ****** Error: Error while identifying Cortex-M device
    Info: TotalIRLen = 4, IRPrint = 0x01
    No devices found on JTAG chain. Trying to find device on SWD.
    Info: Found SWD-DP with ID 0x2BA01477
    
    ****** Error: Error while identifying Cortex-M core.
    Info: Found SWD-DP with ID 0x2BA01477
    No device found on SWD.
    Failed to identify target. Trying again with slow (4 kHz) speed.
    Info: TotalIRLen = 4, IRPrint = 0x01
    
    ****** Error: Error while identifying Cortex-M device
    Info: TotalIRLen = 4, IRPrint = 0x01
    No devices found on JTAG chain. Trying to find device on SWD.
    Info: Found SWD-DP with ID 0x2BA01477
    
    ****** Error: Error while identifying Cortex-M core.
    Info: Found SWD-DP with ID 0x2BA01477
    No device found on SWD.
    
    J-Link>st
    VTarget=3.351V
    ITarget=6mA
    TCK=1 TDI=0 TDO=1 TMS=0 TRES=1 TRST=1
    Supported target interface speeds:
     - 48 MHz/n, (n>=4). => 12000kHz, 9600kHz, 8000kHz, ...
     - Adaptive clocking
     
     

  • All the JTAG pins TCK,TDIN,TDOUT,TMS are connected to 10K ohm pull up to 3.3V.

    What do you mean Ring out?
  • Hi TI Team,


    One card that was stuck in a state that the JTAG isn't accessible
    Was brought back to production and passed the following steps:

    1. The CPU was burned again with SW via the UART0 .

    2. Later on the CPU was burned with Application SW via the Ethernet.

    3. The card with the CPU that runs the SW was again passed the JTAG Unlock procedure.

    4. The Flash was erased but again the JTAG isn't accessible like it was before and the card is stuck.


    I hope that it gives you any idea about the state of the CPU after the JTAG Unlocking.


    Thanks,
    Shlomi
  • Ring out is short for; did you do DMM continuity testing? Don't pressure via probe on pins, use very light touch may reveal poor solder paste wetting to pins. Ring out all MCU pins near case/package entry GND/VDDA have solid connections? Is case getting burn your finger hot or ice cold like no body at home in winter? Have you visually inspected all MCU pins under 5-8 diopter magnification?

  • Should the, 'Elephant in this room' - continue to be 'avoided?'

    Do not an unusually HIGH Number of users - wind up here - w/ 'Similar JTAG Lock-Out Results?'      (other ARM Forums reveal 'far fewer' such "lock-outs" ... and while you 'Seize (solely) upon User Build' ...  do not such 'lock-outs' equally impale (even) 'Official Vendor Supplied' Boards!)       Uh-oh - did the elephant just,  'trumpet?'

  • Though grey area elephants do exist often resulting from poor solder connections, even pin flux residue on occasion. Notice poster debug reports J-Link device, DFU driver may also have some kind of anomaly with who knows what at this point.
  • Does not your 'defense' avoid TWO - 'Key/Critical' Facts?

    • Actual Vendor-Built/Tested Boards - suffer 'Higher than Expected'  JTAG Lock-Out Occurrences
    • Boards - both Vendor-Built/Tested - and User-Custom - from 'others' - experience 'far lower'  JTAG Lock-Out Occurrences

    Admitting that an 'Issue or Problem exists'  - proves the (usual) 'First Step' - in 'driving toward a (real) Solution!'     Neither the vendor - nor hapless users - benefit from such issue's 'known & long' continuance...

  • It sounds to me like the JTAG interface is marginal. While you can program using UART0 and Ethernet without a problem, programming via JTAG or SWD seems to be marginal at best. The JTAG interface is very sensitive to ringing or cross-talk on the TCK/SWCLK line. Note that slowing down the clock speed will not help. It is the reflection of the clock edge that creates the problem. While some scan controllers may be better at suppressing the reflection than others, the part will not work properly if it sees two clock edges when the scan controller only meant to send one edge.

    You might want to look at the JTAG or SDO lines with a scope to see if you notice any cross talk or ringing. If so, here are some things that might help.

    1. Keep the length of cable and traces short. Longer wires allow more time between an edge and its reflection. Also, longer wires are better at picking up cross talk.

    2. Properly terminate the JTAG/SDO clock line. Use a series termination on the scan controller end if there is not one there already, and an AC termination on the TM4C end.

    3. Protect JTAG/SDO signals from cross talk. Ribbon cables should have alternating grounds, or use twisted wires with grounds for each signal.