TDA4VM: Trace Data Pins benefit for "normal" debugging?

Hello Felix,

The MIPI-60 carries JTAG debug (tdi/tdo/tms/...), trigger&control (EMU0/EMU1), trace (TRC_CLK, TRC_DATA0-2x), and power related signals.  "Full debug performance" would require the trace pins.  The trace pins are their to output processor and system trace hardware trace.  Processor tracers come ARM and DSP cores, this consists of a stream of executed instructions and in some cases data addresses and values.  For system trace, hardware collectors provide things like HW generated: bandwidth, latency, transaction-summaries, and critical subsystem event summaries.  Software on any core can also input events into this output path by using the coresight STM message window.  All the events which are output on the trace bus are timestamped using a global source which allows cross core correlations.  The hardware trace stream can be directed into a small internal circular buffer ~64K  which tends to hold ~100uS+/- of events (depending on stream), where the external trace pins allow that stream to be captured by external receivers.  For fast streams this might be up to a 8GB receiver.  Slower streams in some cases can be streamed to a hard drive using 3rd party tools like Lauterbach.

The hardware trace is can be useful for debug, profiling, and in some cases safety certifications.  The HW generated trace streams provide a way for instrumentation free debugging which be highly useful for production code.  On a TDA4 device, the high performance cores like A72 or C7x can generate a lot of trace which requires all the MIPI-60 pins to sink, boxes uses with these would be more like XDS560-protrace, a Lauterbach-PowerTrace setup (or similar tools like dstream from ARM).  The XDS560v2STM support is targeted for narrow trace streams.   Some amount of external trace tends to be better than no external trace so probably its useful to export as many TRC signals as possible, but they must be continuous (0,1,2,3.. to max)  not (1,5,10). 

Application development has many ways to solve issues.  Some folks use trace a lot and some don't use it much at all.  A fully provisioned development board like the EVM provides where production boards might leave it off our just export a few lanes.

Regards,

Richard W.

Hello Felix,

Your summary is correct.  The TRC pins are used to send output only streams of core and system information.  The SOC level constraint coming out this ATBI/TPIU path is the signals must be consecutive as mentioned above.   Some tool's trace receivers may have different constraints about the # of trace pins they support.  Recently I had to ask to get '21' bit support added for a tool to get max bandwidth on a board.  Generally I find the some tool hardware schemes can't efficiently use all their receiver data if the number of lanes is not power of 2, but they still work as long as SW support it.

EMU0/1 signals on TDA4 devices in the debug context can be used to set the initial TAP state (at reset those pins are sampled).  A 1/1 results in standard mode, a mixed mode will result in a WIR (wait in reset) or some internal reserved non-functional test modes.  After reset, EMU0/EMU1 on some TDA4s can be used as external input/outputs to two one wire debug trigger buses.  These triggers can be linked to events like halting or other events.  On prior TI devices like TDA3, these buses were knows as XTRIG.  On TDA4, with C6x devices this still is used in this fashion.  For other cores ARM and C7x, these triggers get translated into coresight CTI channels which are linked by CTMs.  The CTI/CTM concepts are well described in ARM coresight documents.

In previous (TDA3 and before) devices the EMU0/1 pins also could be assigned to have a trace function (EMU0=TRC_DATA0) but for TDA4 this mux option has not been provided.  If you look at debug headers like cTI20 you will see it has EMU0-EMU4 described.  This allowed for a mix of trigger and trace features on a 20 pin header.  For TDA4 devices the trace bandwidth is high enough that a person wanting to debug an A72 probably would just add a MIPI60, but there could be times where a 4-bit (clk+4datalanes) trace on the 5 pins could be useful for CortexM or STM debug streams. 

Regards,

Richard W.