TDA4VP-Q1: XDS560v2 PRO TRACE Receiver & Debug Probe support

Correction, the hardware device we have is the XDS 110-U and not XDS560v2 PRO

Hi Alan Longardener,

Steps to Capture Core Trace in CCS

• Configure the boot mode to No Boot Mode.
• Launch the initialization script using:
  js:> loadJSFile("/home/sivadeepr/Documents/psdk_rtos/ti-processor-sdk-rtos-j784s4-evm-11_01_01_01/pdk_j784s4_11_01_00_17/packages/ti/drv/sciclient/tools/ccsLoadDmsc/j784s4/launch.js")
• In Debug view, right-click on the desired C7x core and select Connect Target.
• Load the executable onto the selected C7x core.
• From the menu bar, navigate to:
  Tools → Code Analysis → Core Trace, and configure the trace settings as required.
• Run the C7x core.
• Once execution is complete, halt the core, then stop the trace capture from the Core Trace window to analyze the collected trace data.
• 

Regards,

Ben

Adding a response from Shabary on a sister thread (  TDA4VP-Q1: [CEER] C7x Priority Handling - JTAG Debugger   - will close that thread and point to this one) for the same topic:

Hi Ross,

Ross S. said:

We need to identify why c7x is not responding in time to high priority requests when it has load that is 

supposed to be low priority.

Is the customer running any TIDL inference on the core at the same time? Are there any other tasks active concurrently? This is important because TIDL may deliberately call Hwi_disable() around long processing blocks to prevent interruptions.

Regards,
Shabary S Sundar

Hello.

We have identified the source of the issue.
It is interrupt disable by TIDL - indeed by default TIDL keeps interrupt disabled for entire operation.

We have found that the issue goes away (the highprio load gets scheduled within deadline, so everything gets processed as in should and FPS returns to 30) if TIDL is configured with maxPreEmptDelay set to 0.

We would like to ask TI why TIDL is diabling interrupts by default and if it is safe to set maxPreEmptDelay to 0.

Our documentation can be found here:
edgeai-tidl-tools/runtimes/examples/cpp/preemption_example at master · TexasInstruments/edgeai-tidl-tools · GitHub

for maxPreEmptDelay = 0:

"...

• Network A: priority 1, max_preempt_delay = 0
• Network B: priority 0, max_preempt_delay = FLT_MAX
• Network B preempts Network A immediately after the current layer completes

..."

Best regards, Stefan

Thanks for pointing us to the TIDL preemption example:
github.com/.../preemption_example

We’ve reviewed it and it aligns with our observations. In particular, with maxPreEmptDelay = FLT_MAX (default), TIDL can defer preemption until an optimal network point, resulting in long non‑preemptible execution windows, while maxPreEmptDelay = 0 allows immediate preemption at layer boundaries and restores C7x responsiveness.

This explains why we see an unacceptable drop from the required 30 FPS to ~15 FPS with the default configuration, and why setting maxPreEmptDelay = 0 restores 30 FPS.

Our remaining question is around supported usage for mixed workloads. The example focuses on preemption between TIDL networks, whereas our system shares the C7x with other latency‑sensitive, non‑TIDL workloads.

We are using C7x as a generic DSP, to quickly run operation over frame buffer. Operation itself takes about 600 microseconds, but has to be performed with low latency, otherwise processing elsewhere does not meet real time.

Likewise, the C7x self‑test is another example of a non‑TIDL, latency‑sensitive workload sharing the same C7x core, and there may be additional non‑TIDL stages elsewhere in the computer vision pipeline with similar latency requirements.

Hi Dale,Nikita,

Reassigning this thread to the appropriate subject expert for further assistance.

Regards,

Ben

Any update?

Hi Devin,

I am sorry, but anything pending on this thread? 

Regards,

Brijesh

Hi Brijesh,

Yes, just one nuance we discussed in our meeting where you confirmed that running TIDL on a C7x shared with non‑TIDL, latency‑sensitive workloads is considered an intended and supported architecture by TI.

And specifically we're looking for confirmation that the TI framework inherently supports L2 SRAM synchronization and sharing between TIDL and non-TIDL tasks.   And that the maxPreEmptDelay is independent of this synchronization mechanism.

Regards,

Devin

Hi Devin,

We are discussing this on the below thread, so can we please close this thread and discuss only on below thread? 

(+) TDA4VP-Q1: C7x Scheduling Degradation Due to TIDL Preemption and Interrupt Handling - Aptiv Jacinto Forum - APTIV - EP Automotive - TI E2E support forums

Regards,

Brijesh

Not everyone interested in this topic has access to the private E2E

Hi Devin,

Sure, 

On this question, if i understand correctly, non-TIDL task is essentially a task running on top of FreeRTOS or SafeRTOS. So unless this RTOS provides L2 coherency (I really don't think so), the non-TIDL task will not be L2 coherent with TIDL task, isn't it? 

When TIDL task is preempted and switched out due to other high priority task, TIDL will save the context (this requires confirmation from TIDL team, i am checking for it). But when non-TIDL task is preempted and switched out due to even higher priority task, most likely non-TIDL requires to save its own context and restore it when it is switched back in. 

One question, can the higher priority non-TIDL task be preempted? or will it always run to completion without preemption?  

Regards,

Brijesh

The non‑TIDL workloads are standard FreeRTOS/SafeRTOS tasks running on C7x. We are not assuming the RTOS provides L2 coherency, and we are not currently doing any explicit L2 SRAM partitioning or coherency management at the application level. One clarification we are seeking from TI is whether any L2‑level constraints or management are required when TIDL and non‑TIDL tasks share a C7x core.

Regarding preemption: TIDL being preempted by a higher‑priority task is expected.

Brijesh Jadav said:

can the higher priority non-TIDL task be preempted?

Thanks for confirming the non‑TIDL task context handling. Just to clarify, by task context we mean CPU/DSP execution state (registers, stack, etc.), which is distinct from L2 SRAM data correctness. With that distinction, there is still a pending question on whether explicit L2 SRAM partitioning or synchronization is required when TIDL and non‑TIDL tasks share a C7x core — is that correct?

Hi Devin,

i have answered this question on the other thread. 

Regards,

Brijesh