Hi,

Working with a TMS570LS3137 powered safety ECU I have to connect to the running target in order to debug with safety outputs enabled.
We use TI Code Composer Studio (CCS) 7, Jlink support installed. The Jlink version is 6.14b. The CCS Jlink drivers includes a Jlink script for the TMS570 MCU (TMS570.JLinkScript).

The script overrides the Jlink DLL behaviour for InitTarget (setting up the TI IcePick ondevice JTAG controller and the JTAG chain) and ResetTarget (Reset via IcePick).

Using Jlink with CCS 'out of the box' it will reset and halt (vector catch) the MCU when connecting (via the TargetReset() in the script).
Thus no attach to a running target possible.

I deactivated the ResetTarget routine in the script to omit the reset of the MCU during connect.
Now I can connect to the running target however the CPU is halted after execution of the connect (InitTarget) routine whereas I would require it to continue running and set a breakpoint via Jlink.
The behaviour is the same for the CCS Debugger and for Jlink commander (both executed with the patched JLinkScript).

To start the target with the safe outputs enabled, you have to powercycle it: Thus i cannot start the target after having connected but have to attach to the running target.

According to the Jlink Control Panel log I assume neither the CCS debugger nor the JLink commander send a "halt" explicitly during the connection process.

Is there a way to attach to a running Cortex R4 MCU with Jlink and keep it running? What else could I check regarding this issue?

Best regards,
Michael

Hi Niklas,

Yep, works like a charm.
Thank you very much!

Unfortunately I did not notice the nice wiki, could have saved us some time

Interestingly, the command string used in the sample script is not documented in the JLink User Manual (UM08001 V6.14, sect. 5.12.1).

Best regards,
Michael

Goal is to use "attach to running target" in TI Code Composer Studio (CCS) with the JLink integration of CCS.

CCS allows for the specification of a JLinkScript file in target configuration (ccxml file). So I specified the JLinkScript allowing the attach to running target (no ECC Init).
Now the CCS debugger connects to the running target, however, it halts the CPU after connecting.

The log view of the JLink Control panel shows, that a JLINK_Halt() API call was invoked (see pic). This is not the case if I connect with Jlink commander (using said jlinkScript).

Is it likely that the JLink adapter driver (JLINK2GTIAdapter.dvr) for CCS issues a connect and a halt when the CCS Debugger invokes connect target?

In CCS debugger setup every checkbox regarding reset / halt target is unchecked...


Best regards,
Michael

Hi Niklas,

thank you for the reply.

Did I get this right: The CCS plugin for JLink executes the JLINK_Halt() after every connect?
Ok then at least I know where it comes from I was quite sure it was the CSS Debugger.

Starting the halted CPU after connect does not work:
Observing our system in action relies on the TMS570 safety (main) CPU and the companion chip (watchdog) running synchronously - that is after a reset or power cycle.
As soon as the main CPU is halted, the companion deactivates the outputs. Thus debugging strategy is to connect to the running system, set some breakpoints and wait until the CPU runs into a break point - then the outputs are disabled anyway. But up to then they are active thus allowing us to monitor the behaviour of the application.

Is there a way to customize / patch the behaviour of the CCS JLINK plugin / driver?

Regards,
Michael

Hi Niklas,

already evaluated Ozone in parallel to my attempts to make things work with CCS.
I will try if I get attach to the running target (and subsequently set some break points while the CPU is running) work with Ozone.
I assume invoking JLINK commands such as the "rnh" (reset no halt) command (jlink commander) is also much easier in Ozone as it would be in CCS..