As a dynamic analysis method of application, I have wrote about printf debugging in the past, but this time also gives you tips about printf debugging.
Contents
Review printf debugging again…
Normally, in order to check whether the code of the application is correct or it behaves as expected, you would stop executing the program and execute the code one by one. Also you may need to check the value of the register and memory.
A printf debugging is effective for dynamic analysis. For details, please refer to the previous article “Printf debug and Semihosting on LPC ”
The way of the debugging is so-called a step execution. It is actually a normal way.
Because the way of these debugging must stop the program once, the program code may not work as expected or the behavior may be changed.
Therefore, such printf debug could even affect the behavior of your program as it executes the printf() function at the least.
Of course, it could affect the behavior of the application just not a part of the code, but as a whole application.
Therefore, dynamic analysis of debugging has to be taken a lot of cares.
ITM Trace function SWO
ITM (Instrument Trace Macrocell) is a lightweight trace function supported by ARM Cortex-M3, M4, and it supports the extended debug function. This traces the OS and the application event (macro function for ITM) as a printf style debug extension function, and outputs the value written in the ITM register at high speed via SWO.
This SWO extension function can be used with Cortex-M3 / M4 and can not be used with the function on Cortex-M0 / M0 +.
This ITM outputs trace information on the debugger console, or its event information can be displayed in chronological order.
In addition, since the ITM module called ARM CoreSight does this itself, there is no load for the CPU core to execute the printf function with no penalty, and it outputs debugging information without affecting program execution.
It is useful for applications that can not stop a program for step execution debugging such as a motor application, or for problem analysis of software and hardware related timing problems.
however, to be struct to say, it is not that it doesn’t affect the execution or behavior of the program at all. I would say that it can dramatically reduce the impact even when you do a printf debugging if you use ITM.
Why not use such a great feature? Let’s use it.
However, there are some limitations when you use this feature. You should make sure it meets the requirements.
NXP MCUs supported ITM SWO feature
Kinetis series:
All K series、KV3x、KW2xD
LPC Series:
LPC13xx LPC15xx, LPC17xx/18xx, LPC40xx/43xx
Cortex-M0/M0+ doesn’t support ITM.
Development environment（IDE）:
Here are some IDE that supports ITM feature.
- IAR EWARM
- ARM Keil
- Atomic True Studio
- MCUXpresso IDE
NXP’s MCUXpresso IDE also does support the feature.
Debug probe：
On MCUXpresso, there is only one debug probe supported, Link Server.
On MCUXpresso, Link server is only supported.
LPC-LINK2 and LPCXpresso on-board ICE only are supported for ITM SWO output. On-board ICE of FRDM board such as CMSIS-DAP, JLINK, P&E multi-link and mbed are not all supported for ITM trace including SWO on MCUXpresso IDE. LPC-LINK2(Link Server) and LPCXpresso onboard ICE(Link Server) are only supported.
Well, let’s go through and try to use it.
Just Try ITM Printf debugging !
For project used for ITM printf debugging, a project for K64 will be used.
Preparation
Hardware
- FRDM-K64F
Development environment（IDE）to be used
- MCUXpresso IDE
MCUXpresso IDE is a free of charge and no code size limitation. It is a very good tool for hobby-use and company development use.
You can download it from here（Download NXP MCUXpresso IDE from here)
Debug probe to be used
- LPC-LINK2(CMSIS-DAP)
LPC-LINK2 is to be used. Since on-board ICE of FRDM-K64 board doesn’t support SWO feature, LPC-LINK2 is used this time as external debug probe.
Board connection
If you plug USB micro in J26, the on-board ICE is supplied and running. LPC-LINK2 SWD debug interface conflict with the on-board ICE SWD.
Therefore, you may want to plug USB micro cable in J22 USB just for power supply as you can see the below picture. Then, you can avoid conflicting the SWD interface so that you can make a connection properly with the target device.
Software project to be used
Hello world project is used.
MCUXpresso SDK for K64 is used.
Sooo Easy! To Use SWO Output.
It is actually so easy to use ITM SWO output. Creating new project automatically on MCUXpresso IDE sets SWO output .
In order to use SWO, it is necessary to prepare global variables to pass parameters from ITM event to C libraries, and that function is necessary. This function is also automatically included in the project when you create new project with ITM printf enabled. .
Ok, let’s see the new project creating wizard.
Run MCUXpresso IDE
You can specifiy a folder wherever you want to place for workspace of MCUXpresso IDE project.
Create A New Project
We are creating a project and import sample code of “Hello world” this time.
Select Evaluation Board
Select a board that you want to use, then click next.
For use of FRDM board, you need to get SDK prepared beforehand. For creating SDK, there is a past article of『MCUXpresso SDKTutorial:How to generate SDK』. You can refer to it and make sure that SDK is available beforehand.
You can import the SDK by means of drag&drop the ZIP file of SDK created by MCUXpresso SDK tool, into a window like below picture of “Installed SDKs”. FRDM-K64 is now imported.
Select Project
Configure C library option
This configuration is important when you use ITM SWO output feature.
And, Newly and newnanolib library should be able to use for ITM, but unfortunately it fails when it builds. Redline library only works well. I hope NXP will fix it soon.
Select Redlink’s library and select the checkbox of redirecting “PRINTF” to the C standard library printf (“Redirect SDK” PRINTF “to C library” printf “).
And then, check the ITM printf/scanf that is our purpose this time (redirect printf/scanf to ITM), and click Finish.
Build project
Let’s build, then since we have done importing the demo project of Hello world.
Start debugging
Click Debug from the Quick Start view to start debugging.
Configure SWO
When it starts debugging, it stops(breaks) at the top of the main() function. You might want to configure SWO configuration here.
SWO output configuration can be done in the tab, Trace Config”.
The clock speed must be set to exactly the same as core clock you use, so that SWO can access the CPU core.
FRDM-K64F maximum clock is 120MHz, and the hello world sample code set it in default.
You have to set the SWO clock to 120000000Hz.
When it was stops at the top of main(), the initialization of clock setting was not yet done. The clock is supposed to be 20.975MHz which is default frequency.
If you set the SWO speed to 20.975MHz, SWO won’t work well. You have to set 120MHz.
You can open ITM Console, then.
SWO printf output is dispelled in SWO console
If you release and start debugging, it just flips back to normal console display, but you might change it to SWO console again.
You may see “Hello World.” in the SWO console.
Even Scanf() can be done in the hello world project. The sample code always monitor scans() by means of while loop.
You may want to type in, then characters you typed show up. You should hit the enter at the end. Then, the same characters are displayed by printf again.
Summary
ITM printf debug suppresses the influence on the behavior of the program and can perform Printf output and scanf input at high speed.
When dynamic analysis is required, ITM Printf debugging is effective.
For MCUXpresso IDE, there is no special setting, ITM Printf can be automatically included into the project simply by enabling ITM Printf at project creation, so you can easily debug using ITM Printf.
Why not try with ITM printf debugging on MCUXpresso IDE?
Thank you so much for your reading to the end. If you think it was good! It would be greatly appreciated if you could share it.