Good day
I am debugging an RT1176 processor with NXP's MCU-Link Debug Probe. I would like to obtain detailed information about the interrupts in my project, so I tried to configure the project for SWO Tracing.
These are the steps I followed:
- Configure the CSTRACE clock in the “Clocks” ConfigTool view to have a 132MHz frequency:
- In the “Pins” ConfigTool view, enable the SWO pin and route it to one of the two given options:
- In the “Routing details” view in the “Pins” ConfigTool view, the default setup for the pin is given in italics. Click the dropdown menu for each accessible option and re-select the default value. This will change the setup parameters to normal text (not italics). This ensures that the code is generated for these settings. I have previously found that using these ‘default’ (italics) values as is can cause a pin not to work as expected.
- Click "Update Code" in the ConfigTools view.
- Start a debugging session
- In the “SWO Trace Config” window, configure the “Clock speed” to 132MHz.
- Use the various SWO Trace views’ start/stop controls to trace
To verify my SWO Tracing setup, I followed the above steps on the eaimxrt1176_cm7 Embedded Artist SDK example project. Note that one must enable the Pins tool for the project before the changes to the pins can be made (because it is an SDK project).
According to the project's main(), the PIT interrupt should occur once per second:
However, the trace shows that it only occurs about once every 7s (see "measured interval"):
The Cortex M7 core root clock is set to 996MHz. It seems like the SWO tracing is using the core root clock to determine the interrupt timing, instead of the CSTRACE clock. This could explain the multiplier of approximately 7, since 996/132 = 7.54.
I have the same problem in both MCUXpresso v11.5.1 and MCUXpresso v11.6.0.
Is this a bug in the SWO Tracing of the RT1176? Is there a known fix?
Thanks in advance.
Update @Pavel_Hernandez @jingpan @kerryzhou
I tested out my earlier hypothesis as to why there is a timing problem.
In the eaimxrt1176_pit_cm7 example, I decreased the M7's clock frequency to 264MHz (I couldn't decrease it to 132MHz because the required prescaler value is out of bounds). I left the CSTRACE clock frequency at 132MHz. I clicked "Update Code" in ConfigTools.
I decreased the timer period to 1s:
Then I ran the debug again, and again set the SWO config clock speed to 132MHz.
Now the 1s interrupts occur every 1s 999ms - proving that M7_cloc_freq / CSTRACE_clock_freq is the factor that is unaccounted for in the SWO trace's time calculations.
I have uploaded my project too, so that NXP can download it and try it out for themselves.
Please could NXP get back to me on this with a fix or work-around, as soon as possible.
Thanks for the threads. I have read them, and unfortunately they do not address my issue.
So far, I have been working with the MCU-Link external debugger, my employer's own PCB and JTAG connection, and Embedded Artists' RT1176 uCOM board.
However, I have just reproduced the problem on NXP's RT1170-EVK, with the evkmimxrt1170_pit_cm7 SDK example (SDK version 2.12.0).
Follow my steps below:
- Using this post by Kerry, I changed the RT1170-EVK's onboard debugger's firmware to LPC-LINK2 CMSIS-DAP. This allows SWO tracing on the EVK with the onboard debugger.
- I imported the evkmimxrt1170_pit_cm7 SDK example (SDK version 2.12.0).
I navigated to the "Pins" perspective of ConfigTools for this project, and "routed" GPIO_LPSR_11 to ARM SWO. - I navigated to the "Clocks" perspective of this project's ConfigTools, and confirmed that the CSTRACE clock has a frequency of 132MHz.
- I clicked on the ConfigTools "Update code" button to add the ARM SWO pin configuration to the project's code.
- I debugged the project with the onboard debugger (now LPC-LINK2 CMSIS-DAP):
- I opened the "SWO Config" window and clicked on "Change" clock speed, and changed the value to 132MHz.
- I navigated to the "SWO Interrupts" window and clicked on the "Resume data display" button (green play button).
- I waited for a few minutes, and then I clicked on the "Pause data display" button (yellow pause button).
- I clicked on the "Perform Auto Scale" button, and then used the "Horizontal Measurement" button to measure between interrupts. As you can see below, the interrupts are measured as 7s apart:
The SDK example configures these interrupts to occur once per second (1s period), so there is clearly something wrong with the SWO tracing.
The fact that I could reproduce this problem on the RT1170-EVK with its onboard debugger proves that the MCU-Link Debug probe is not the cause of the problem. It also proves that it is not to do with Embedded Artists' RT1176 uCOM board. This allows NXP to debug this internally.
@Pavel_Hernandez If you follow the above steps, you will be able to recreate my problem on an RT1170-EVK.
Please let me know if you have any further information.
D_TTSA.
To further specify the cause of the problem, I followed the above steps, but using the evkmimxrt1170_pit_cm4 SDK example (also using SDK version 2.12.0, RT1170-EVK and its internal debugger with LPC-LINK2 firmware).
Now, the SWO tracing is performed on the Cortex-M4 core.
See the result below:
Now the interrupts measure as 2s 975ms apart instead of 1s apart.
This brings me back to one of my first few posts in this thread. I said that I believed that the factor offset is the traced processor core's root clock frequency divided by the CSTRACE clock frequency.
In the evkmimxrt1170_pit_cm4 example,
the Cortex-M4's root clock frequency = 4320/11 = 392.7272...MHz:
The CSTRACE clock frequency is still 132MHz.
Therefore, the time factor that is shown in the SWO tracing is:
This confirms that my above hypothesis is true - the timing error factor is equal to the traced processor core's root clock frequency divided by the CSTRACE clock frequency.
This also shows that the problem is not specific to the Cortex-M7 core.
I believe it is a problem with the MCUXpresso IDE's SWO tracing software for the RT1176.
Please follow up with the relevant NXP team and get back to me on this.
D_TTSA
