TDA4VH-Q1: TDA4VH SoC Debug

Hi experts：

       More specifically, we want the device.h header file for TDA4VH in the ctoolslib library. The attachment is the definition of J721E platform.

J721E definition:（$(dir)/ctoolslib_J721E_DRA829_TDA4VM_v0.2/build/dra8x9/device.h）

device.h

Hi Li 

We are checking on this , will update you within a week.

Regards
Diwakar

Hello Li,

For TDA4VH the trace config, capture, and decode process is only supported via a connection of a JTAG debugger (commonly CCS, but others also work here like TRACE32).   The information to setup up probes for the tool can be found for the current CCS install at C:\ti\ccs1250\ccs\ccs_base\emulation\analysis\dpk\devices\j7ahp\*.

For TDA4VM (aka J7ES) the options to use the tools allowed for either a target setup or a jtag setup.  For TDA4VH only a JTAG setup is currently supported.  For both targets post processing did require CCS decode tools.  Its notable that the self-hosted setup for debug resources is firewall blocked by current TI firmware which runs on targets so any attempted porting (using the tool specific config files) would require more changes then one might assume.  The JTAG debugger is not effected by the firmware as it accesses the trace resources on a debug address plane (APB) and not the system address plane used by the processors. 

Hi Richard W.

1. The On-Chip debug module (dbgcell, CPTracer2...) address space of the TDA4VH platform on SDK8.6 can be read and written. It seems that this is not restricted by the TI firewall. The Linux test program code is based on ctoolslib_J721E_DRA829_TDA4VM_v0.2

2. From the AETT_property_ks3_system_trace_j7ahp.xml file, we have learned about the TraceAggregator of MSMC_0/1, but the following probe seems to be somewhat different from J784s4. According to the description, CSI8_TARGET, CSI9_TARGET, CSI9_INITIATOR correspond to SoC 0/1 (NavSS Northbridge 0/1), but J784s4 TRM , shouldn't this be the 11/12 Coherent Interface? and 1/5/6/7 Coherent Interface is not reflected in AETT_property_ks3_system_trace_j7ahp.xml

Thanks

Hello Li,

The figure in the TRM version you are looking at is incorrect.  I had filed a bug on this a while back and a fix should show up in a future TRM.  A fix up looks like the below picture which should match the tool file.

Hi Richard W

1. Yes, we are using GP devices. You don’t seem to have explained the coherent interfaces of A72SS1 , this CSI1 probe is not defined in the AETT_database_ks3_j7ahp.jsonc.

2. The following tables are analyzed based on the AETT_property_ks3_system_trace_j7ahp.xml file. Can you help me check to see if they are correct?

Hi Richard W

Is there a more detailed explanation about the master-to-route-ID assignment. We didn't find it in the j784s4 TRM.

Hi Richard W

3. We use CCS to import tdf, but the TDF browsing window is blank.

Hello QuanLi,

-1-

The getting started document in the J721E ctools provides the command lines needed for bin2tdf and td commands.  They are not matching what you are doing above.  The -app option is not used for system trace.  As you guess, it makes no sense as there is no elf object information needed to decode system trace, that is only needed for processor trace.  I would suggest following the examples in ctools the lib sources.

- bin2tdf.exe -bin "c:\temp\CPT2_ddr_throu.bin" -rcvr ETB -output "c:\temp\CPT2_ddr_throu.tdf" -procid stm -devicekey 0x0bb6402f -dcmfile "c:\temp\CPT2_ddr_throu.dcm"

- td.exe -bin c:\temp\CPT2_ddr_throu.tdf -rcvr ETB -output c:\temp\CPT2_ddr_throu.csv -procid stm -devicekey 0x0bb6402f –timestamp abs

Hi Richard W

Ok, use the trace decoding command you provided to convert the .csv file. This is the same as what we see in CCS: go to "Tools" menu and select "Hardware Trace Analyzer->Open File->.tdf".

1. On TDA4VH, the TBR buffer is 64KB. When collecting data, this space is quickly used up, causing new data to overwrite old data. Is there any documentation on trace data, for example, how long is a piece of data and what is its format? In this way, we can roughly analyze the correctness of the data.

2. We just want to know the Master IDs of CPTrace2 probes, because it seems that the CPTrace2 probes configuration seems to require the master id value, such as the MSMC_0 probes mentioned in the AETT_property_ks3_system_trace_j7ahp.xml file:

The Master IDs of some CPTrace2 probes you mentioned above cannot be found in the file.

3. What is the clock/tick of CPTrace2 probes? This involves the calculation of the sampling period.

4. 0x0bb6402f is the devicekey for TDA4VM, which is not fully applicable to TDA4VH. When testing the CPTracer2 probes that both TDA4VM and TDA4VH have, using this devicekey, the trace data can be parsed, but when using TDA4VH’s proprietary CPTracer2 probes, the parsing format does not seem to be correct. . Or the current CCS does not fully support TDA4VH, and we are using version 12.5.0.

Hello QuanLi,

A CPT-throughput message will have this format.  I believe its wrapped in the STPv2 protocol which is outlined in MIPI specs.

The message provide the total bytes during a sample interval.  The default without changing registers is 16mS period for the 1GHz MSMC bus clock.

Hi Richard W

The format we are talking about is incorrect, it is the format converted by the `td` command. The following figure are obtained using the following commands:

PS > C:\ti\ccs1250\ccs\ccs_base\emulation\analysis\bin\bin2tdf.exe -bin memcpy_nocache_ddr_throughput_example.bin -rcvr ETB -output memcpy_nocache_ddr_throughput_example.tdf -procid stm -devicekey 0x0bb6402f -dcmfile memcpy_nocache_ddr_throughput_example.dcm

PS > C:\ti\ccs1250\ccs\ccs_base\emulation\analysis\bin\td.exe -bin memcpy_nocache_ddr_throughput_example.tdf -rcvr ETB -output memcpy_nocache_ddr_throughput_example.csv -procid stm -devicekey 0x0bb6402f -timestamp abs

DDR_EMIF0 Throughput:

However , DDR_EMIF1 Throughput:

Obviously, the format of the DDR EMIF0 interface is correct, while the format of DDR EMIF1 is wrong.

We are not very familiar with the MIPI STPv2 protocol. Do you have any source code examples that support parsing this format?

Hello QuanLi,

Thanks for providing the output you see.  It does appear like the raw numbers might be OK but the name substitution is not working.  I will look to submit an issue report to the CCS owner.

I have not looked into STMv2 protocol decode examples to give a concrete pointer.  I have hand and (T32 tool assisted) decoded some sequences in the past as part of looking into low level issues, but I didn't work with the actual tool code.  ARM does have an opencsd project which I believe should have a free decode example.

I made a quick check at data received on my TDA4VH board on different channels and I do see the HW is presenting the data fine.  The issue seems to be with the CCS decoder here.  The TDA4VM only has 1 channel, so perhpas that porting needs a tweak.

I made a recording using the TDA4VH setup at my desk:  /cfs-file/__key/communityserver-discussions-components-files/791/tda4vh_5F00_cpt_5F00_emif1_5F00_2_5F00_2023_2D00_10_2D00_30_5F00_19h03_5F00_39.mp4

Hi Richard W

Yes, the data should be correct, but the output format is wrong.

Have you modified the CCS decoder to support TDA4VH, and may you provide bin2tdf and td tools for ARM64? We may want to parse the data directly on the board.

When we verified CPTrace2, we also found this phenomenon, which may also be a BUG.

On TDA4VH, the four DDR controllers are configured with an interleaving granularity size of 128 bytes by default.  If 1KB bytes are copied, each of the four DDR EMIF interfaces should be 512 bytes (READ + WRITE). The following figure shows the memory transaction with 1KB bytes copied through the DDR
EMIF0 interface:

This result is consistent with the theoretical analysis. Now let's copy only 640 bytes, so the DDR EMIF0 interface should still be 512 bytes. The following figure shows the memory transaction with 640 (0x400 - 128 * 3) bytes copied through the DDR EMIF0 interface:

From above figure, we can see that the transmitted bytes are 544 (512 + 32) bytes, and the extra 32 bytes in the bandwidth statistics are due to two more transmissions: (Read: 0x8020000C0, Write: 0x8020001C0).

Hi, Richard W.

1. Thank you for your reply. We basically confirm that the ctoolslib_J721E_DRA829_TDA4VM_v0.2 library can support TDA4VH after being extended. Currently we have temporarily created an STM devicekey to support TDA4VH, such as `0x0bb7503f`.

The `j7ahp-in-development` directory contains .jsonc files under development that support TDA4VH. Then we can use the `bin2tdf` and `td.exe` tools to decode trace data.  This is working fine. 

There may be CCS parsing tools left in the future that may need your support.

2. Regarding the extra 32 bytes, we actually discovered this phenomenon through bandwidth statistics. In order to analyze this reason, we captured the transaction logs. I will provide more detailed information below, which may be helpful to you. 

The following table shows the memory bandwidth with (0x300000 - 128 * 3) bytes copied:

The following table shows the memory bandwidth with (0x300000 - 128 * 2) bytes copied:

The following table shows the memory bandwidth with (0x300000 - 128 ) bytes copied:

The following table shows the memory bandwidth with (0x300000) bytes copied:

This happens every time.

3. Yes, the statistics about cache are relatively complicated, and it is difficult to theoretically analyze the exact value.

Thanks

QuanLI.

Hello QuanLi,

It is very positive that you were able to successfully extend and use the cptracer2 feature in ctools lib on TDA4VH. I hope you will be able to leverage this in your development. I will look into recreating your finding of an extra data read and share it with a designer who worked with this IP block. Its my impression the issue likely will not stop productive use of the engine however it is something which should be understood.  Thanks.