TMDSCNCD263: How To Connect The Target To The Debugger Without Suspending It?

Hello Kier,

Please see this similar thread regarding the autolaunch properties, if it is able to help resolve your inquiry: 

https://e2e.ti.com/support/tools/code-composer-studio-group/ccs/f/code-composer-studio-forum/241840/running-the-program-automatically-after-launching-it 

Best Regards,

Allison

Thanks Allison but this didn't help.

I've already disabled the items that may cause it to suspend:

Perhaps it's not possible with this processor. That's fine but need confirmation of that please.

Hi Kier,

Let me double check on this for you - I will update tomorrow after confirming.

Best Regards,

Allison

Hi,

Please see this video: https://www.youtube.com/watch?v=xEBjObfW-8Y

Best Regards,

Ben Collier

Thanks Ben but not applicable. The key step in the video is to disable 'Halt the target on a connect'.

That isn't even an option for this SOC as it's greyed out:

I guess this backs up my hunch that this SOC doesn't support it what I'm after but it would be good if the experts would confirm that...or not.

Hi Kier,

Our usual Debug expert is out today and will be able to look at this on Monday. My uninformed lean is that we probably don't support that due to not having embedded Flash.

Best Regards,

Ralph Jacobi

Hi Kier

I think (+) [FAQ] AM2634: How to debug / monitor a variable in running state - Arm-based microcontrollers forum - Arm-based microcontrollers - TI E2E support forums can solve this issue. Please let me know if you need anything else.

Thanks

Hi Sanmveg,

Thanks but that FAQ doesn't match my use case. The FAQ is about monitoring a variable without halting the target. My problem is that the target is unavoidably halted when I connect. This is about connection.

Kier said:

My problem is that the target is unavoidably halted when I connect.

You are looking for a non-intrusive connect where the debugger can establish a JTAG debug connection without halting an already running CPU. A halt can be triggered from three areas:

1) The debugger itself. There is a debugger option to issue a halt request on connection. You already know about this option and it is desabled.

2) GEL_OnTargetConnect(). You know about this too since mentioned you removed the GEL startup scripts.

3) The device (requires it). The actual device needs to support a non-intrusive connect. This is typically supported by devices that have full real-time mode support. (this differs from just real-time memory access). ARM based devices do not have this full real-time mode support but I believe we added at least the ability for a non-intrusive connect to some of the ARM cores like Cortex-M3/4 and A15. At least those are the ones that I can find information on. I don't see anything for Cortex-R so I would have to investigate.

There appears to be a known issue with non-intrusive connect for Cortex-Mx. I suspect it impacts other devices. I'm pushing to restart investigation on this issue.

Many thanks.