Logging is very important for developing embedded products, especially for connection based wireless products because the use of breakpoints will probably result in dropped connections. Whereas, we can easily address problems by walking through the log. This article will introduce a simple implementation of logging on EFR32 based devices. The key point of this article is to introduce a way to classify the log into different levels, and each level of log has its own identifier.
Let’s start with 2 design sketches, which demonstrate outputting the log via RTT and VCOM(UART).
Figure 1. Using RTT
Figure 2. Using VCOM
From the pictures, you can see the different level of logging uses different colors, this article introduces 5 levels of logging as below.
|Type||Error(Highest Level)||Warning||Information||Debug||Verbose(Lowest Level)|
Table 1.Log types and colors
The symbol LOG_PORT, defined in log.h, can be set to SEGGER_JLINK_VIEWER or PORT_VCOM to determine which terminal the output should be sent to.
The definition of LOG_LEVEL in log.h determines which level of logging should be output to the terminal. As you can see from the table 1, error has the highest level while verbose has the lowest level. For example, If the LOG_LEVEL is defined as information level, then error, warning and information log will be sent to terminal, the debug and verbose log which have lower level than information will not be sent to the terminal. See figure 3, which shows the log as information level without modifying anything from figure 1.
Figure 3. Log with information level
There are 5 corresponding functions to send the log, the input parameter of these five functions is the same as standard printf();.
Follow below steps to enable this feature in your project and customize it to meet your requirements.
After all the above is done, your project should be able to send the log to the terminal.
Is it possible to use the RTT Viewer while putting the device in sleep mode? It appears that when I use connect to the device using RTT Viewer, the MCU stays awake permanently. I'm on a EFR32BG13P. It would be great if this debug method would be usable simultaneously with the Energy profiler (even without code correlation).
Sorry for the late response, but I don't think so, at least in my daily use of the RTT, it seems the device never sleeps.