CCS/TMS570LS3137: CCS Debugger: Attach to running target / no halt during connect

Hi,

>>Of course in the debug properties of the project nothing is checked regarding reset / halt the target; "Halt target on connect" is greyed anyway.

I see the same thing. I suspect that either CCS does not implement this option or it is completely unsupported on this Debug Probe (I couldn't find such option during my internet searches).

>>Or is there a way to send driver commands directly to the underlying (Jlink) driver by DSS script? -> DSS target.connect(); of course shows the same behaviour as hitting the "connect to target" button.

DSS is completely dependent on what is supported or not by the emulation device drivers.

I will check with some people and report back.

Regards,
Rafael

Hi Rafael,

thank you for your reply.

The option (connect to the running target) is supported by the JLink debug probe / drivers (after the modification of the script). Tested it using Seggers command line tool JLink commander. 

However, it is unclear, what the CCS specific driver (ccs_base/emulation/drivers) for JLink does resp. what interface / API it presents to CCS. It ist definitely based on the JLINK dll (JLinkARM.dll) driver: The Segger control panel shows that JLinkARM.dll is used when connecting with the CCS debugger.

I am quite sure, the halt during Connect Target is issued by the CSS Debugger:

I assume the driver (JLINK DLL) implements a couple of basic functions such as "connect", "halt", "run" (API to the debugger). Why should it automatically execute connect and halt when only the connect API is invoked by the debugger?

I will also consult Segger about that.

There must be a (CCS) layer between the JLink emulation driver and the CCS debugger / DSS. Is there a way to log the driver API calls invoked by the debugger?

Regards,

Michael.

Hi,

To check whether the Halt API call to the emulator driver during CCS "connect target" comes from the CCS debugger I enabled the debugServer logging in CCS.

The LOG file is appended.

GTI_HALT appears only on lines 228, 289. I assume all commands / GTI calls are declared here.

GTI_CONNECT appears in the declaration section (470 - 475) and at line 9827 where the actual connect appears to be started.

After GTI_connect has finished (line 9831), at line 9840 there is the an entry stating that "Target execution state changed to STATUS_HALTED"

Is there an entry between line 9831 and 9840 indicating that the debugger invoked functionality which somehow could halt the target?

Regards,

Michael

0x000018D0 25471 3 PERF I: GTI_CONNECT finished: 0.689475s wall, 0.187500s user + 0.078125s system = 0.265625s CPU (38.5%)

0x000018D0 25471 3 CortexR4 GTI C: GTI_GETERRSTR_EX2( 0x4D891408, *0x3EAEEAC8 = 0x00000000, *0x3EAEEACC = 0x00000000, *0x3EAEEAC4 = 0x3EAEEFB8, *0x3EAEEAD0 = "(nullptr)" )
0x000018D0 25471 3 CortexR4 GTI R: GTI_GETERRSTR_EX2( 0x4D891408, *0x3EAEEAC8 = 0x00000000, *0x3EAEEACC = 0x00000000, *0x3EAEEAC4 = 0x3EAEEFB8, *0x3EAEEAD0 = "(nullptr)" ) = ""
0x000018D0 25471 3 CortexR4 STATE I: Connection state changed to 4
0x000018D0 25471 3 CortexR4 POLL C: Firing DSP_DOMAIN_POWERED to all DSP_USER's
0x000018D0 25471 3 CortexR4 POLL C: Firing of DSP_DOMAIN_POWERED complete
0x000018D0 25471 3 CortexR4 GTI C: GTI_STAT( 0x4D891408 )
0x000018D0 25472 3 CortexR4 GTI R: GTI_STAT( 0x4D891408 ) = 0x00000001
0x000018D0 25472 3 CortexR4 STATE I: Target execution state changed to STATUS_HALTED

Log File:

CCS_debugger.log

Michael,

Please apologize for the lack of updates. I have been working on this issue during this week and I am also checking if Segger can identify anything on their driver that may be influencing this.

So far, what I found is:
- The option "Halt target on connect" is enabled only for a few cores (C2000, MSP430 but not ARM).
- For C55x and C66x cores, enabling the option "Enable realtime mode" does the same effect as disabling "Halt target on connect".

Therefore I am trying to get a confirmation if this is, in fact, supported by the Cortex cores.

Regards,
Rafael

Michael Holzmann said:

Is there a way to customize the behaviour of connect to target of the CCS debugger?

Of course in the debug properties of the project nothing is checked regarding reset / halt the target; "Halt target on connect" is greyed anyway.

I think   the SEGGER J-Link Support (Windows) 6.16.4.0 update has fixed the problem. With SEGGER J-Link Support (Windows) 6.16.4.0 CCS 7.2 allows the "Halt the target on a connect" option to be selected when a J-Link is used for a TM4C Cortex-M device. The Segger Release notes for J-Link V6.16d says one of the changes is:

TI CCS Plugin / Installer: In older versions, J-Link always performed a Halt() when connecting to the target. From now, we evaluate the "Target Halt On Connect" project option property.

[I haven't tested this myself]

Hi all,

There is something else at play for Cortex R cores. Despite the feature included in the Segger updated package is working (no more JLINK_Halt() calls on the log), my TMS570LC4357 board still halts during connect.

My TM4C1294 Launchpad, however, connects without halting as expected.

I am disabling all the breakpoints (so the target does not need to be halted for them to be set) and, obviously, the relevant option.

I will keep trying to make it work here on these cores. 

Regards,

Rafael

Hi everyone,

With the help of Segger support I was able to track the reason of this behaviour on Cortex R devices.

Since the TMS570/RM4x devices in question have ECC RAM that is not initialized at power up, the debug probes connect and properly initialize this memory during the init phase. Therefore, to help bypassing this behaviour you would need to disable the ECC RAM routine. 

Just FYI, Segger also mentioned the ICEPICK JTAG Router requires a proper reset before connecting, thus disrupting the normal execution of the core. However, I suspect this will not affect the TMS570s as other devices that have the same ICEPICK Router (such as AM335x) are not affected by this. 

Segger provided a small script attached to help with that, but please keep in mind this is provided as-is without warranty or support. 

Hope this helps,

Rafael

TI_TMS570LC.rar

Hi Rafael,

thank you for your continued efforts in this regard.

I already found out about the EEC RAM init issue with the help of segger. But I think the script is a different one. It can be found in the segger wiki:

wiki.segger.com/.../TI_TMS570Lx_SkipECCInit.JLinkScript

It solves the ECC init issue (JLINK command "SetSkipInitECCRAMOnConnect = 1"). Thus you can connect to a running target with e.g. the JLINK command line tool. However you still can not connect to a running target in the CCS Debugger due to the CCS JLINK driver issue discussed above (sending a halt on every connect).

But now, as you wrote, that there is a new jlink Version which seems to adresses this problem. I did not try it yet, but as soon as i can confirm I will let everbody here know.

Combining both, ECC RAM init script and the new JLINK Driver, it should finally be possible to connect to a running target from the CCS Debugger :)

Best regards,

Michael