i.MX8QXP debug trace options

cancel
Showing results for 
Search instead for 
Did you mean: 

i.MX8QXP debug trace options

1,235 Views
EAlepins
Contributor V

Hi,

i.MX8QXP (ARM Cortex-A35) has debug trace feature. However, I am a bit confused about:

1) The information tracing provides. Do you have a list? There is at least:

  • profiling (functions duration and number of calls)
  • object code coverage
  • But is there other information as well? For example cache misses/hits; PMU data; other interconnect's traffic information; etc.?

2) I think there are no external ETM pins to the SoC. Hence, I understood there were 2 means to output trace data:

  • on-chip: store data to DDR (can it be stored elsewhere?)
  • off-chip: stream data outside of SoC. I saw on the Internet PCIe bus used for that. But does the i.MX 8X is limited to using that bus or any other would work?

3) Does trace data pass by the central SoC interconnect (DRAM Block + Big Node) or is has a dedicated internal bus? If through the SoC interconnect, then I can't see how ETM tracing can be non-intrusive. There will be application performance degradation when tracing is enabled. Am I right? Do you have examples showing the percentage of interference obtained?

4) PCIe intrusivity: same question, but for off-chip tracing through PCIe. Trace data traffic going through PCIe will collide with applicative's PCIe data. Do you have examples showing interference? Or an applicative PCIe occupation threshold (X% PCIe bandwidth) below which adding PCIe trace has no significant impact?

Thanks,

Étienne

0 Kudos
5 Replies

1,223 Views
igorpadykov
NXP TechSupport
NXP TechSupport

Hi Étienne

 

I asked internally and got below :

------------------------

For Linux BSP, we support OProfile, which can be found from Linux BSP reference document:

Chapter 2.6 OProfile.

And in Linux BSP, we can use followed command to track the DDR loading:

     perf stat -I 1000 -a -e ddr0/read-cycles/,ddr0/write-cycles/,ddr0/cycles/

 

We don't have tools to track PCIE.

------------------------

Best regards
igor

0 Kudos

1,217 Views
EAlepins
Contributor V

Hi,

Thanks for your answer. However, we will not be using Linux. And when I was mentioning PCIe, I was not talking about sniffing the PCIe traffic but rather use the PCIe bus as a mean to export the tracing information generated inside the i.MX 8X SoC.

My question is not related to tools provided by NXP, but rather to understand the tracing capabilities at HW level of the SoC itself. Can you help on my initial questions?

Thanks,

Étienne

0 Kudos

1,205 Views
vincent_aubinea
NXP Employee
NXP Employee

Hi,

You can get in touch with Lauterbach, they have solutions to perform ETM -> ETR -> PCIe -> external PowerTrace on i.MX8.

Regards,

Vincent

0 Kudos

1,208 Views
igorpadykov
NXP TechSupport
NXP TechSupport

 

------------------------

For the ARM core debug trace, I think the customer can check ARM Technical Reference Manual, the hardware interface is the JTAG interface. 

I haven't seen special trace functions on iMX8X soc.

 ------------------------

Best regards
igor

0 Kudos

1,190 Views
EAlepins
Contributor V

Hi,

i.MX 8X trace functionality is described in Reference Manual (IMX8DQXPRM) §Chapter 6 "Debug Architecture" and §6.2.1 ETR and §6.2.2 ETM. So there is trace support in i.MX 8X.

What I am not able to find is the interference that ETM will cause in the i.MX 8X SoC:

- Are the trace information sent on the same interconnect as used by the rest of the SoC? (Cortex-A35, etc.) (i.e. on DB Ram and Big Node)

- Does NXP has experience or projects that showed how much PCIe interference the trace was causing? For example, using PCIe Gen 2,for a full SW running on 4 Cortex-A35 cores, how much % of the PCIe bandwidth is occupied by trace data? Or any other data you have giving me an idea of the order of magnitude of the performance drop caused by the trace.

Thanks,

Étienne

0 Kudos