Software development for microcontrollers is often difficult. With few exceptions, microcontrollers offer some sort of debugging solution that can start and stop the processor and allow the contents of variables and registers to be examined. This helps determine the cause of a problem. However, many manufacturer boards, such as Arduino Uno or BBC micro:bit, do not have such support natively, leaving the developer to repeatedly edit and upload code until the source of the problem is found. found.
But debuggers aren’t always the panacea they seem to be. When developing real-time code for Ethernet, Wi-Fi, or USB, or in applications such as motor control, you can’t just stop the microcontroller’s intermediate throughput. This causes communication disruption and can even damage power devices, if a MOSFET is caught in its on state.
Because of the ease with which serial output can be initiated on maker boards, most developers add textual debug output to their code by sending messages to a terminal on a PC via USB. When analyzing the output after a test run, the developer can trace the path the code took, hence why this method of debugging code is known as “software tracing”. It also allows debugging of applications that cannot be stopped during operation.
Thousands of innovators use the web Elektor Labs Platform to share electronic projects and find new ideas. Join them on Elektor Labs! Present your electronic projects. Submit your articles to Elektor editors. Showcase your products for the Elektor Store. All you need is a free Elektor ID.
The project
Regular Elektor Labs Laurent Labbe often uses the serial interface to trace execution of embedded code, but does not always have a spare laptop to log messages. This led him to wonder if there was an alternative approach. Armed with a ESP32an OLED screen and a 3D printer, he imagined the “Wireless trace for debugging” project.
The approach uses an ESP32 as a buffer for debug messages, connected to the target controller by a serial interface; the buffer is made accessible via Wi-Fi and a web server (Figure 1).
The massive amount of SRAM on the ESP32 allows for the implementation of a giant circular buffer. Laurent’s projects typically use a low baud rate of 9600, but this can be changed. Each time a character is received, it is pushed into the circular buffer head. The buffer is 65530 bytes (unsigned characters) in size, so there is plenty of space to collect trace messages. Series1 is initialized for data collection using pins 25 and 26 (TX and RX, respectively), although only the RX pin is required. Because the ESP32 is a 3.3V device, Laurent has included a resistor/diode circuit to allow 5.0V microcontrollers to be connected to the serial interface (Figure 2).
As noted, the project uses the Wi-Fi capability of the ESP32, which is where this design shows its uniqueness. After registering with the network as defined in the code, any local laptop or mobile device can access a web page offered by the ESP32. The ESP32 then serves up a simple page that includes the current contents of the circular buffer (picture 3).
Second network, serial interface and display
There are also a few other cool features built into the code. For example, a second SSID and password for another Wi-Fi router is supported. If the first link fails for some reason, the ESP32 will automatically attempt to connect to the backup. With potentially hours or days of data stored on the device, this provides more robustness in retrieving trace messages. The web server uses port 80 by default, but another port can be set on initialization.
The circular buffer also implements looping. Thus, if the buffer is completely full, new incoming messages overwrite the oldest data. For clarity, the web page includes an appropriate message before displaying the contents of the circular buffer from oldest to newest.
The ESP32 also sends messages via the Serial interface (on USB), allowing to debug the code of this project. Debug messages received via Series1 went out to Serial for immediate visibility. All data received on the Serial interface is also inserted into the circular buffer.
IP address information and other relevant details are transmitted to an I2C-based OLED display connected to pins 4 and 5. The display used is Adafruit’s SSD1306 with its driver and GFX graphics libraries.
Laurent used a WeMos Lolin32 OLED (Figure 4, the board is based on the ESP32-WROOM-32 module with additional circuitry) to implement the USB to UART interface and support for connecting and charging a LiIon/LiPo battery. With its 3D printed case, for which a CAD file is provided, this wireless debug trace tool can be deployed almost anywhere to collect data from your target autonomously (Figure 5).
Choice
The beauty of this project is the combination of its simplicity and expandability. The functionality of the code is clear, which makes it easy for experienced developers to extend and modify this project. For example, expanding available SRAM using external devices wouldn’t be difficult, and you could even store trace messages on an SD card. Serial interface speeds for data logging can also be matched, or data from an I2The C or SPI interface could be collected instead. Finally, if your posts require a bit of color or formatting, you can insert the appropriate HTML or CSS code when generating the web page.
Questions about debugging or software?
Do you have any technical questions or comments about this article? Email Elektor at editor@elektor.com.
