• State TI Thinks Resolved
  • Locked Locked
  • Replies 11 replies
  • Answers 1 answer
  • Subscribers 32 subscribers
  • Views 1650 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.

Using EK-TM4C123GXL as a Programmer/Debugger for a Custom Board

Scott Li17
Prodigy 240 points
Other Parts Discussed in Thread: EK-TM4C123GXL, LMFLASHPROGRAMMER, UNIFLASH

So starting with the problem: After reading through the application note www.ti.com/.../spma075.pdf I am trying to program a custom board using the EK-TM4C123GXL on-board ICDI. I get the error "Could not initialize target device! Please power cycle the board and try again"

However, using my J-Link debugger, I am able to detect the SWD device and apparently program it. But this seemly "locks" the device. I am unable to connect in debug mode or flash it again. I still have not been able to fix this problem. (I've tried LMFlashProgrammer.) At this point I'm thinking that might be able to be avoided, if I can get to debugging with ICDI. (My attempt with programming using the ICDI is on a fresh custom board).

Being able to flash the custom board using J-Link, in addition to checking and seeing all the VDD VDDA VDDC pins are at the correct voltages, should be an indicator that the custom board is good. (or should it?) 

So I'd like to ask: Firstly, if anyone, that has successfully used the EK-TM4C123GXL on-board ICDI to debug an custom board, can verify it works with SWD and not only JTAG, and that no external oscillator on the custom board is required. Any other tips/information for this use case in addition to the application note would be appreciated. 

I don't think the problem is pin mismatch from the custom header connections for the on-board ICDI. Other than the power rail pins on the custom board, and the fact that I can programming it using a J-Link debugger, I can think of any conclusive test to determine that the custom board is good or bad...

  • 0
    TI__Guru 72500 points
    When using the EK-TM4C123GXL as a scan controller for another board, it uses JTAG, not SWD. You need to verify that the JTAG TDI and TDO signals are also properly connected.

    Does your software configure PC[0-3] as GPIO? This could be the cause of the device "locking" after being programmed by the J-Link.
  • 0 in reply to Bob Crosby
    Guru 117855 points
    Adding to Vendor Bob's useful reply - firm/I (always) find that the use of "real" (external) pull-up Rs on each JTAG line greatly assists "connect."
  • 0 in reply to Bob Crosby
    Prodigy 240 points
    Hmm. Under Keil's debug options for ICDI, SWD is a selectable option, and I am able to successfully program and debug the EK-TM4C123GXL using it. Which means this option could be a bit misleading if all JTAG pins are used... But I would be very happy if this is the problem. Only SWD is implemented on the custom board, so I will solder the unconnected JTAG TDI Pin directly to the microcontroller and see if this resolves the issue.

    PC[0-3] are not being used.

    Thank you for your suggestions.
  • 0 in reply to Scott Li17
    Guru 117855 points
    We too use a J-Link pod - always & only in SWD - and have debugged & programmed hundreds of LX4F (early vendor MCUs) as well as TM4C123. (our IDE is IAR)

    Vendor's Bob has noted that, "Vendor's ICDI does NOT support SWD." That limitation does not extend to your (or our) J-Link - but DOES explain why you MUST complete all JTAG interconnects when using vendor's ICDI.

    We find the J-Link vastly superior - difficult to grasp why you'd employ the (lesser) vendor ICDI...
  • 0 in reply to cb1_mobile
    Prodigy 240 points

    Thank you for the information. I originally decided to try the ICDI after referring to this thread forum.segger.com/index.php. My since my J-Link appears to have locked my custom board as well... At this point my tests show that the problem is with my custom board.

  • 0 in reply to Scott Li17
    Guru 117855 points

    "Usual suspects" for dreaded "board locking" are:

    • Repurpose of (any) PC0-PC3 pins from their default JTAG/SWD defaults
    • Mismatch between your board's external (main oscillator's) crystal and your System Clock's crystal parameter

    The J-Link is the top selling JTAG/SWD pod - has pre-existed vendor's ICDI - has long supported SWD - is vendor agnostic - use of (any) lesser device is (very) hard to justify.

  • 0 in reply to cb1_mobile
    Prodigy 240 points
    Yes, I have had a good experience with another J-Link, different from the one I'm using right now. Just thought I'd try another option in hopes of getting things to work at the time. At this point is quite clear that the issue isn't from the debugger for many reasons. I've found that the debugger is unable to pull down the reset pin on my custom board. It does work on the EK-TM4C123G, as expected. Both board have a 10k pull up for the !RESET pin...
  • 0 in reply to cb1_mobile
    Guru 13040 points

    cb1_mobile said:
    The J-Link is the top selling JTAG/SWD pod - has pre-existed vendor's ICDI - has long supported SWD - is vendor agnostic

    Hello cb1,

    Every time I read this - often commented by yourself - I remember I have a yellow pod in my drawer, and that I need to configure and use it with my CCS/Tiva environment! They date back to my MSP430/IAR days, but the pod is probably still better than the XDS100 and 200 that I now use...

    Maybe later this month, when I get back to the old continent.

    It is my turn now to deal with a set of 5 new-design custom boards with TM4C1294 which are not being "detected by the debuggers"... All voltages are proper at 3.3V and 1.18V, no GND shorts or into wrong pins, no other GPIO's or HIB or WAKE out of the expected. No excessive current. JTAG lines are proven good, and we tested all sorts of debugger options (ICDI from launchpads, XDS100v2 and XDS200). Reducing clock from 8MHz to 1MHz did not work, nor did trying to unlock via UniFlash or LMFlahs. We don't have pull-ups on the JTAG lines, so that's the next attempt for this afternoon. If that does not help, we will attach the scope into the JTAG lines and try to see what's wrong...

    Cheers

    Bruno

  • 0 in reply to Bruno Saraiva
    Guru 117855 points
    Feel your pain. High value, internal MCU pull-ups INVITE signal reflections AND rounded edges - both able to confound JTAG or SWD.

    Through use of a J-Link (on sale as an Educational device) you may switch to SWD which our firm & others find superior. (and free 2 GPIO for your (sure) use!) The cost/size penalty imposed by 4 (or 2) 06-03 smt (JTAG) pull-up resistors makes their AVOIDANCE very hard to justify.

    Your JTAG signal lines (especially the clock) should AVOID other switching signal lines - should be short/direct - and ADEQUATE board power must be supplied during the programming exercise.
  • 0 in reply to cb1_mobile
    Guru 13040 points

    cb1_mobile said:
    Feel your pain. High value, internal MCU pull-ups INVITE signal reflections AND rounded edges - both able to confound JTAG or SWD.

    Thanks...

    The pull ups did not do the trick. I'll search for other posts on the matter. If not found, I'll start a new thread with a proper title and details of what's done so far.

    Bruno

  • 0 in reply to Bruno Saraiva
    Guru 117855 points
    If you wish send me (via forum's PM) a (good) photo of your board - especially revealing the placement of bypass & filter caps in (very) close proximity to the MCU.

    You report "measuring 3V3 & 1V8" - that's best done via a scope - looking for noise and/or ripple - especially (while) you are attempting the program operation. (measurement via DMM is not likely to"catch" such issues)

    What current do you measure - and have you monitored the "current surge" during power-up?
    Have you "measured" the "cap load" upon VDDC - it is critical that you comply w/MCU's spec. (Good "R-L-C" meter "shines" there)

    If not "board layout, inadequate ground creation/routing and/or other routing errors" - would it not prove best to "systematically" (starting w/VDDC components) transfer those power related components from a "working board" to your "undetected board?"

    Firm/I "avoid" such issues by "pre-screening" and quarantine of such components - insuring they ALL are "w/in spec, otherwise proper" prior to the board build/assembly. Such caution - surprisingly - has never appeared here! (till now)

    We "have" been able to "attach & connect" via a "J-Link" (newer, black case) when client's ICDI attempts failed! (and this - far more than occasionally)