Qt on iMX6ULL Part 2: Logging messages and settings for debugging

In the previous article, Qt on iMX6ULL Part 1: Hello, LED On/Off, we developed a Qt Widget application that controls an external relay module connected to a GPIO. Please take a look at the final result by checking out the video.

Other articles in this series:

• Qt on i.MX6ULL Part 0: Installation and Initial Setup.
• Qt on iMX6ULL Part 1: Hello, LED On/Off.

In this continuation, we will be delving into some essential debugging techniques that can help us trace the execution of an application.

Our exploration begins with thoroughly examining the Qt logging utility and ends with configuring the environment to enable Qt in runtime debug mode.

So, let's get started!

Hardware requirements

The hardware configuration for this tutorial will consist of the following components:

• Toradex SoM: Colibri iMX6ULL 512MB IT V1.1A.
• Toradex Board: Aster V1.1B.
• Toradex Display: Resistive Touch Display 7" Parallel.
• A single-channel relay module 5V/10A.

Qt logging utility

Whether you're a firmware or software developer, you've probably used a print function, like printf or std::cout, to monitor program execution at some point in your career. Nothing to be ashamed of! ;-)

In Qt, we have a better way to do this. It provides a global C++ macro to log warnings and debug messages. You can access this link for more details. Those logs are categorized into five types: qDebug; qInfo;qWarning; qCritical; and qFatal.

Let's return to our project to see how this works!

Note: I have created a new project with a more generic name called DemoProject, which can be utilized in future articles. This project is the same as the one created in Part 1 of the article.

Qt Warning and Debugging Messages

To open the Qt project in Qt Creator, click on Open Project and then navigate to the folder named Part2-DemoProject. From there, select the file labeled DemoProject.pro.

To begin, we will start with a basic test involving logging messages. To do this, open the main.cpp file and include the QDebug header by adding #include <QDebug>. Then, add the following lines of code to call the Qt logging functions:

#include "mainwindow.h"

#include <QDebug>

#include <QApplication>

int main(int argc, char *argv[])

{

    QApplication a(argc, argv);

    MainWindow w;

    w.show();

    qDebug() << "Debug message.";

    qInfo() << "Info message.";

    qWarning() << "Warning message.";

    qCritical() << "Critical message.";

    qFatal("Fatal message");

    qDebug() << "This message cannot be reached!!!";

    return a.exec();

}        

After that, build the project and run it on our target board. Open the Application Output, in the lowest part of the Qt Creator, to see the log messages.

Take a look at the log messages. Observe that the last qDebug message was not printed.

Why not? This happened because the application was closed after executing the qFatal message.

Ok. But it's not a big deal until now! Let's work on enhancing those log messages.

In Qt, we can customize log messages to include more information. One way to do this is by using qSetMessagePattern.

Go back to the main.cpp and add the following line of code:

int main(int argc, char *argv[])
{
    qSetMessagePattern("[%{time yyyyMMdd h:mm:ss.zzz} %{if-debug}D%{endif}%{if-info}I%{endif}%{if-warning}W%{endif}%{if-critical}C%{endif}%{if-fatal}F%{endif}] %{file}:%{line} - %{message}");

    // ... (content remains unchanged)        

We have created a new message format for logging. Build and run the code to see the enhanced log message.

Take another look! It's now possible to see the data, time, file, line number, and, of course, the message that we wrote.

This is way better than the default log! However, notice that those messages are written out on Qt Application Output or target console if you start the application directly on the target board console.

Another improvement could also be to store the messages on a file. Let's go!

Create a custom message handle

We'll create our own message handle and pass it to qInstallMessageHandler function. In this way, it'll be written out and stored in a file at the same time. Update the code as in the image below:

Access the GitHub repository to see the whole project.

Note 1: That implementation is not thread-safe!

Note 2: It could be an improvement to limit the file size.

Build and rerun the application. Notices that the messages continue to be printed out on Application Output. However, if we access the target board via the USB/Serial Debug port or SSH connection this time, we'll see on the logfile.log on /home/root/ folder.

Could you guess which messages have inside?

Adding log messages to our project

It's time to move the log messages to a better location in our application. Start by removing the ones added in the main.cpp, but keep qSetMessagePattern and qInstallMessageHandler functions.

Open the mainwindow.h and include the QDebug header. After that, update the mainwindows.cpp as in the image below.

Build and rerun the application. Press the ON and OFF buttons sometimes. Can you spot similar messages?

Setting the runtime debug environment

So far, we've delved into using Qt log messages.

This time, instead of clicking the Run button (represented by the Green Arrow), try pressing the Start Debugging of Startup Project button (the Green Arrow accompanied by a Bug). When you do this, you'll encounter the following error:

This issue arose because we hadn't configured the environment variables that give Qt the necessary information to establish a runtime debug connection. Let's set this right!

Got to the Project button on the left sidebar. Under Build & Run, choose the Run option in the iMX6ULL section. Scroll to Environment and click Details. Hit the Add button and input the variable names and values as displayed in the table below:

| Variable name   	| Variable value    	|
|-----------------	|-------------------	|
| XDG_RUNTIME_DIR 	| /tmp/runtime-root 	|
| QT_QPA_PLATFORM 	| wayland-egl       	|
| WAYLAND_DISPLAY 	| /run/wayland-0    	|
| DISPLAY         	| :0.0              	|        

Upon completing this, your configuration should mirror mine. Although this rectifies the initial error, there's still more to address!

Try starting the Debugger using the Start Debugging of Startup Project button once more. You'll likely see another error pop up in the Application Output window.

To fix this new one, first, stop the Debug mode. Go to Edit > Preferences > Debugger and select the GDB tab. Uncheck the Use automatic symbol cache. In the Additional Startup Commands field, input the following command: add-auto-load-safe-path /opt/tdx-xwayland-upstream/6.3.0/sysroots/armv7at2hf-neon-tdx-linux-gnueabi. Click Apply, then Ok.

Before initiating the debugging process, set breakpoints within mainwindow.cpp, specifically inside the MainWindow::on_btnOn_clicked and MainWindow::on_btnOff_clicked functions.

Click on the Start Debugging of Startup Project button and observe whether the application launches.

On the target display, click either the ON or OFF button and turn your attention to Qt Creator. What's happening?

If you selected the ON button, the application's execution should pause within the MainWindow::on_btnOn_clicked function.

Fascinating, right?

Press the F5 key to resume the application's execution.

Now, give the OFF button a go and witness the magic unfold once more!

Removing the Weston toolbar

Did you think that I had forgotten?

We must access and modify the /etc/xdg/weston/weston.ini file to remove the toolbar.

Start by uncommenting the [shell] line and add the panel-position=none configuration, as indicated below. Reboot the target after that, and voilà!

Conclusion

Debugging is an essential skill for any developer, and the Qt environment offers a rich set of tools to assist you. By understanding the Qt debug message feature and setting up your application to runtime debug mode, you're better equipped to diagnose and solve issues that may arise.

As you continue to work with Qt on iMX6ULL, this knowledge will be invaluable.

Stay tuned for more insights and tips in the next article of this series.

See you there!

Links:

• GitHub repository.
• Warning and Debugging Messages.