CCS/TM4C129ENCPDT: Timeout error on Debug

As poster mentions "20x4" (actually 4x20) Lcd - turning OFF the Lcd's backlight when "long enough idle" will reduce a (likely) unneeded (when not in use) current draw.

Drawing excessive current from any USB Port may "damage that Port" - while greatly "convenient" - USB Port is much limited power-wise - and must not be over-stressed!

Just as vendor's Charles had, "Never heard nor seen such issue" - we share that newness.     Disturbed power may well account for such issue.

"Careful & Proper" provisioning of a "real supply" (applied so as NOT to DAMAGE the "continuing" USB Connection - which enables debug & programming) proves the best means to confirm, "Proper Power as the FIX!"

Charles Tsai said:

I did some search in the forum but not really finding relevant posts that have similar problem as you reported.

I think when a program is running the CCS debugger is regularly polling the state of the target, and under some conditions the status poll fails with a debug error.

From memory the error is most likely to occur when the running program is polling a peripheral in a tight loop.

cb1_mobile said:

I can report that in (over) 10 years of J-Link usage (at least 5 in near daily use - past 7 years via SWD, exclusively) firm/I have (never) noted any such, "Timing Out"

a) Got an error with a Stellaris ICDI ("Error: Timed out while waiting for target powerup/polling a hardware resource")

b) Got an error with a Segger J-Link ("Error: Stat [ JLINKARM_IsHalted() call ] failed!")

c) Didn't get an error with a XDS110.

In the case of the Segger J-Link found that the act of lowering the JTAG frequency appeared to make the problem go away - see https://e2e.ti.com/support/microcontrollers/tiva_arm/f/908/p/518418/1885271#1885271

cb1_mobile said:

which appears to confirm Chester's report of "Debug Probe limitation" as a (likely) cause...

Chester Gillon said:

Not sure that the issue is a "Debug Probe limitation", but rather an interaction between the CCS debugger, debug probe and program running on the target.    For a definitive explanation think I would need to try and capture the JTAG / SWD signals when the error occurs.

Those two points you've introduced ascend, "Atop the mountain!"     Highly analytical - and superbly describe (both) the "issue" (it really appears to be an "interaction") and then proceeds to specify a "Real diagnostic method (capture then compare JTAG/SWD transactions during (both) "normal/failed" transactions)...  

While my report (no such "time-out" noted w/J-Link(s)) rises (little) beyond anecdotal - it is "long duration" - which (suggests) - yet fails to conclusively establish it - as proven fact.

Building upon your idea, (Attempt to deliberately "provoke" the (unwanted) time-out behavior) we may join to create the identical, "tightly looping (polling) an MCU peripheral" code block" using (both) vendor's ICDI and modern J-Link Probes.      (I should be able to run at least 3 J-Links simultaneously - via different PCs - attached to 3 '123 LPads.")      Such seems (reasonably) conclusive - to determine the "degree of guilt" (if any) introduced via the differing probes.     (although our system is pre-set to SWD (only) - we've "liberated" those other 2 pins for GPIO usage...)

As you & I have long noted here - this vendor's MCUs seem (pardon) especially prone to, "Loss of JTAG."     (Yet - either thru "skill" - or luck - or our exclusive use of "J-Link & SWD" - firm/I (almost) never - note such issue.)    

I've thought that a dedicated creation of a variety of, "JTAG/SWD" transactions - may yield "insight" into, "What triggers such JTAG LOSS?"     (beyond the trivial, "Re-purpose of  PC0-3 and Butchering of SysClock.")    Again - via strength of numbers - our "exclusive" J-Link usage appears to "resist" this issue - yet we read (endlessly) of ICDI users falling victim.    (while ... "Rome sleeps" ... (swear I heard (someone) say that...)

It would be "helpful to many" if such "JTAG failure trigger(s)" could be identified - and (some) defense developed.      (or we could devote time/effort to, "Destroy LIKE!" ... ... yet - that's already been done.)

Chester Gillon said:

Looking back my previous posts:

a) Got an error with a Stellaris ICDI ("Error: Timed out while waiting for target powerup/polling a hardware resource")

b) Got an error with a Segger J-Link ("Error: Stat [ JLINKARM_IsHalted() call ] failed!")

c) Didn't get an error with a XDS110.

- CCS 7.3.0.00019 under Windows 10
- TI Emulators 7.0.48.0
- SEGGER J-Link Support (Windows) 6.20.9.0

While the previous program which showed the error was "polling a peripheral in a tight loop", it was also outputting data from UART0 at 115200 baud continuously. Created the attached example which runs on a EK-TM4C1294XL and outputs continuous characters on UART0 by calling the TivaWare UARTCharPut(). Where UART0 on the target TM4C1294NCPDT is connected to the "Stellaris Virtual Serial Port" on the on-board Stellaris ICDI. TM4C129_peripheral_poll_tight_loop.zip

The results were:

The conclusions are:

a) While previously had got a "Error: Stat [ JLINKARM_IsHalted() call ] failed!" in June 2016 with CCS 6.1.3, with the latest CCS 7.3 and Segger J-Link can no longer repeat the error.

b) With the latest CCS 7.3 can still get a "CORTEX_M4_0: Error: Timed out while waiting for target powerup/polling a hardware resource" with a Stellaris ICDI, but only when Sellaris Virtual Serial Port is also being used to receive serial characters from target. Therefore, suspect the cause of the error is in either the Stellaris ICDI firmware and/or software driver.

Thank you - very "well done" & reported.

Note that the "duration" of each debug session may come into play.    (poster lists only, "after running for some time" - which denies the chance for others to (fully) replicate his report...)

From the ongoing, "JTAG LOST" reports - it is this area - by far - which requires attention.     (and continues to be (pardon) notably avoided - which enables, "low hanging fruit" (such as banning the motivational "LIKE") to (needlessly/unjustifiably) absorb vendor time/resources.)

Your report today - which casts suspicion upon vendor's ICDI implementation - points as well to that ICDI as, "prime suspect" in causing dreaded, "JTAG LOSS/Lockout."      Again - w/FIVE J-Links in (near) daily use - I cannot recall our last, "JTAG/SWD Lock-Out!"     (to be fair - our usage is most always via SWD - and we (properly) employ ARM MCUs from 4 vendors ...yet the '4C123 sees (near) daily use.)

cb1_mobile said:

Note that the "duration" of each debug session may come into play.    (poster lists only, "after running for some time" - which denies the chance for others to (fully) replicate his report...)

Using the Stellaris-ICDI with the Stellaris Virtual Serial Port open left the program running in the CCS debugger with the CCS debugger sampling a counter at 2Hz (this uses the DAP to access memory via JTAG while the target continues to run). In this test got the "CORTEX_M4_0: Error: Timed out while waiting for target powerup/polling a hardware resource" error after a few seconds to 18 minutes of running.

In an attempt to determine if the problem is in the Stellaris ICDI firmware or CCS debugger ported the test program to run under IAR Embedded Workbench for ARM 8.11.2 (the free code size limited version). The program has run for the last four hours without error, with output on the Stellaris Virtual Serial Port. However, when IAR is used with the Stellaris ICDI are unable to access memory while the target is running in that the "Live Watch" option is greyed out. Therefore, the test with IAR is inconclusive since not sure if the IAR debugger is performing JTAG accesses while the program is running. 

Thank you - again well detailed - very much appreciated.

Firm/I have "multiple seats" of Paid IAR.   (dongle protected)     W/in the next few days (as staff returns) [we note that often - "recovery from vacation" IS required...] we will download & install that "code-size ltd. version - and see if "Live Watch" is indeed blocked.

(I believe that on an earlier version of "free" IAR "Kickstart" the "Live Watch" WAS present - and performing - even when we (held our nose) and launched the "ill behaved" ICDI.    (Rather than the (vastly superior) J-Link...)    Do note that we have "no interest" in '129 family" use only (past LM3S, LX4F) and '123 - I am 80% certain that IAR's "Live Watch" did succeed when "J-Links" were "all tied up" and we ran '123 via ICDI...     (note: fire-axe & No-doze - both at the ready...)

We shall try - then report - again thank you...