MIMXRT1170-EVK: How to enable instruction trace on the RT1170 evaluation board?

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

MIMXRT1170-EVK: How to enable instruction trace on the RT1170 evaluation board?

Jump to solution
4,510 Views
mrd
Contributor III

I have a Segger J-Trace Cortex-M debug probe and want to enable instruction trace (ETM Trace) on the RT1170 Evaluation Board.  What needs to be modified on the board?

I have installed 0-ohm resistors R1881, R1882, R1883, R1884, R1885, and R1886 (schematic page 7 lower right) so that TRACE_CLK, TRACE_SWO, and TRACE_D3:0 are connected to the RT1170, but it still does not work.  The J-Trace complains of "Unknown trace data packet detected".  I have checked for opens & shorts in the trace connections.  Seems okay.  I have also tried 1-bit and 4-bit trace width.

Are there any parts that need to be removed to allow instruction trace to work?

Has anyone else made instruction trace work with a J-Trace or any other debug probe?

I am using Segger's pre-compiled iMXRT1176_M7 demo project for the RT1170-EVK that is here.  Segger's instructions say that "some solder bridges had to be closed" and to consult the board's manual, but I don't see anything about this in the demo board's user guide

Any help would be very much appreciated!

0 Kudos
1 Solution
4,386 Views
mrd
Contributor III

In case anyone else is trying to get the RT1170-EVK to work with Segger's J-Trace, here's what I found:

Segger verified that they have done the work-around for ERR050708 errata.

Segger also verified that the only modifications needed to the RT1170-EVK is installing 0-ohm resistors R1881, R1882, R1883, R1884, R1885, and R1886.

The primary change that allows instruction trace to work is to adjust the sampling point of the TRACE_D0-3.  Segger's example here defaults to +2ns adjustment.  This does not work...their example (which uses just 1-bit width) should have had 0ns adjustment.  I verified that 0ns works with 1-bit, but when I enabled 4-bit trace, I got more errors.  Adjusting sampling by -0.5ns for all 4 trace lines seems to have solved the problem.

The next step to getting trace to work for an application that runs from the QSPI Flash is to modify the Ozone.jdebug trace debugger script file per this web page: https://wiki.segger.com/Debug_on_a_Target_with_Bootloader#ROM_bootloader .  The main thing is to do what is at the bottom of the page and make AfterTargetDownload() and AfterTargetReset() empty functions so that the RT1176's ROM loader does the SP and PC initialization.

Another thing to know is that Segger's troubleshooting says to use their J-Trace Pro Webserver application to see the "half-sync detection" status, but this always indicates an error on the RT1176 even when trace is working.  Segger technical support said this does not work due to NXP's pattern.  Segger will be updating their documentation.  The best way to determine if instruction trace is working is to change the trace timing configuration in Ozone.  Stop the application and then restart it.  If the instruction trace window starts displaying data and there are no errors in the console, then it is working.

Instruction trace on the RT1170-EVK using Ozone seems to be working well now, but I do occasionally get "Trace overflow detected. Trace packets may have been lost." errors in the console.  Segger technical support said this was because the RT1176 trace clock rate is too low in relation to the 1GHZ processor speed.  The only solution is to reduce the processor speed.  It looks like the RT1176 always uses a 50MHZ Trace Clock.  I don't know if this can be increased or not yet, but seems adequate most of the time as long as using 4-bit trace width so I'm happy with this for now.  This Segger webpage has more info.  https://wiki.segger.com/J-Trace_overflow_error .  #1 is the error condition I'm intermittently seeing.

I'm building the application using MCUXpresso, but debugging using Segger's Ozone when I need instruction trace capability.  Hopefully someday, instruction trace capability will be added to MCUXpresso...

View solution in original post

11 Replies
4,475 Views
jingpan
NXP TechSupport
NXP TechSupport

Hi @mrd ,

MCUXpresso IDE supports SWO trace for RT1170. Instruction trace capture is supported only in conjunction with an MCU’s Embedded Trace Buffer (ETB) or Micro Trace Buffer (MTB).
Unfortunately, neither is implemented by RT1170, so instruction trace is not supported on MCUXpresso IDE.

Other probe vendors may offer support for ETM-based trace capture in other IDEs. For J-Trace details please refer to Segger.

 

Regards,

Jing

0 Kudos
4,466 Views
mrd
Contributor III

Hi.  Thank you for the reply.  I know that MCUXpresso does not currently support ETM trace. [It would be wonderful though if NXP added this sometime.]  I am using Segger's Ozone debugger, which does support ETM instruction trace.

The question I'm asking is what hardware modifications need to be done on NXP's MIMXRT1170-EVK (RT1170 evaluation board) rev C1 to allow ETM instruction trace to work. Is it only installing 0-ohm resistors R1881, R1882, R1883, R1884, R1885, and R1886? Or do some parts need to be removed to decrease loading on TRACE_CLK, TRACE_SMO, or TRACE_D3:0?

Since NXP designed the MIMXRT1170-EVK evaluation board, it seems like this should be information that NXP would provide, but I cannot find it in the user manual. The EVK's designer obviously intended for the board to support ETM trace since it is mentioned in the board's rev C revision history on page #1 of the schematic. Also, page #27 of the schematic labels J58 connector as "Cortex Debug + ETM".

Please provide instructions about which parts need to be installed (added) and if any need to be removed from MIMXRT1170-EVK rev C1.

Thank you.

0 Kudos
4,451 Views
jingpan
NXP TechSupport
NXP TechSupport

Hi,

Installing 0-ohm resistors R1881, R1882, R1883, R1884, R1885, and R1886 is enough.

 

Regards,

Jing

0 Kudos
4,448 Views
jingpan
NXP TechSupport
NXP TechSupport

Hi,

In RT1170 errata, there is a ERR050708. Debugger can not access ROM table by default. I wonder Jtrace may can't access ETM or TPIU if there isn't workaround driver.

 

Regards,

Jing

0 Kudos
2,254 Views
jackking
Senior Contributor I

@jingpan  Can you confirm if this same approach for ETM trace will work for MIMXRT1170-EVKB?   I made the same setup, but never get a TRACE_CLK signal.  

 

I confirmed the PCB trace is connected properly to the MCU by creating a GPIO project to toggle the same pin and using an oscilloscope on the ETM header pin and I can see the pin changing, so it is something about the TRACE_CLK configuration that is not working.  The EVKB seems somewhat different than the original MIMXRT1170-EVK.

 

Any help is appreciated!

0 Kudos
2,219 Views
mrd
Contributor III

Hi.  I don't have the EVKB version of the evaluation board.  I compared schematics briefly.  The only difference I saw that may be causing the problem is that they changed the 10/100mbs ethernet chip from KSZ8081 to RTL8201.  The TRACE_xxx signals are connected to the ethernet chip and may need to be disconnected on the EVKB board for the trace feature to work.  [If NXP tech support sees this, please let us know.]  For the EVKB version, NXP has added 0-ohm resistors so that TRACE_xxx signals can be isolated from the RTL8201.  For example, R1290 could be removed to disconnect from TRACE_CLK.  See picture below.  The trace feature is very helpful for debugging, but its too bad one has to give up using the 10/100 ethernet interface.

mrd_0-1687952912417.png

 

2,209 Views
jackking
Senior Contributor I

Thanks for the reply. I have also removed the ethernet related jumpers, it had no effect on the TRACE_CLK signal.

With the GPIO test, I can confirm that the TRACE_CLK pin of the ETM header is connected and controllable by the MCU.

I have tried both the Segger Ozone Trace sample project as well as some of the NXP MCUXpresso SDK samples and the TRACE_CLK signal is never output.

0 Kudos
4,387 Views
mrd
Contributor III

In case anyone else is trying to get the RT1170-EVK to work with Segger's J-Trace, here's what I found:

Segger verified that they have done the work-around for ERR050708 errata.

Segger also verified that the only modifications needed to the RT1170-EVK is installing 0-ohm resistors R1881, R1882, R1883, R1884, R1885, and R1886.

The primary change that allows instruction trace to work is to adjust the sampling point of the TRACE_D0-3.  Segger's example here defaults to +2ns adjustment.  This does not work...their example (which uses just 1-bit width) should have had 0ns adjustment.  I verified that 0ns works with 1-bit, but when I enabled 4-bit trace, I got more errors.  Adjusting sampling by -0.5ns for all 4 trace lines seems to have solved the problem.

The next step to getting trace to work for an application that runs from the QSPI Flash is to modify the Ozone.jdebug trace debugger script file per this web page: https://wiki.segger.com/Debug_on_a_Target_with_Bootloader#ROM_bootloader .  The main thing is to do what is at the bottom of the page and make AfterTargetDownload() and AfterTargetReset() empty functions so that the RT1176's ROM loader does the SP and PC initialization.

Another thing to know is that Segger's troubleshooting says to use their J-Trace Pro Webserver application to see the "half-sync detection" status, but this always indicates an error on the RT1176 even when trace is working.  Segger technical support said this does not work due to NXP's pattern.  Segger will be updating their documentation.  The best way to determine if instruction trace is working is to change the trace timing configuration in Ozone.  Stop the application and then restart it.  If the instruction trace window starts displaying data and there are no errors in the console, then it is working.

Instruction trace on the RT1170-EVK using Ozone seems to be working well now, but I do occasionally get "Trace overflow detected. Trace packets may have been lost." errors in the console.  Segger technical support said this was because the RT1176 trace clock rate is too low in relation to the 1GHZ processor speed.  The only solution is to reduce the processor speed.  It looks like the RT1176 always uses a 50MHZ Trace Clock.  I don't know if this can be increased or not yet, but seems adequate most of the time as long as using 4-bit trace width so I'm happy with this for now.  This Segger webpage has more info.  https://wiki.segger.com/J-Trace_overflow_error .  #1 is the error condition I'm intermittently seeing.

I'm building the application using MCUXpresso, but debugging using Segger's Ozone when I need instruction trace capability.  Hopefully someday, instruction trace capability will be added to MCUXpresso...

1,949 Views
auftrag2021
Contributor III

your post was SO GREAT for me as the newbie user of segger JTRACE PRO.

Before I saw your article I was so desperated about the segger probe.

Now I still have two questions: 

1. how do you adjust the "-0.5ns" for the 4-bit traces. Do you use a high-end oscilliloscope to monitor the trace data signal quality?

2. after I follow your instruction, I can now have a much stabiler communiction between the probe and imxrt1170evk. But the trace performace disappoint me a little. Do you know how to downgrade the 1GHz  of CM7 core to a certain value? 

0 Kudos
1,933 Views
mrd
Contributor III

Glad you found the post useful.

1) Timing was adjusted via trial & error.  No scope was used.  Even a really good scope probe would likely put too much capacitive load on the high frequency trace signals to be able to make useful measurements.

2) I use MCUExpresso ConfigTools>Clocks to edit the Cortex M7 Core Root Clock.  The excerpt below shows 792MHZ used with industrial grade RT1176.  I still frequently get trace buffer overruns at this clock rate, but it works well enough that I can eventually get a good trace when I'm debugging a problem where trace is useful. 

ConfigToolsClocks.png

0 Kudos
1,921 Views
auftrag2021
Contributor III

thank for your kindly feedback. 

just for your interesting: 

I downgraded the ARM PLL to a VERY low level. (168MHz)

Why 168MHz? because in the SEGGER JTRACE delivery there is a small test board with SMT32 chip which has 168MHz as system clk. 

What amazing me is, the instruction trace function in Ozone worked so well by this STM32 test board. I can smoothly play the trace record permanently without any trace overflow. 

but with the imxrt1170 evk, I still frequently have trace overflow problem. I also tried with some other frequencies, nothing better. 

 

0 Kudos