Industrial automation facilities are increasing the use of microcontroller-based single-board computers (SBCs) to control facility operations in order to increase efficiency and improve productivity. Often the SBCs used are a combination of off-the-shelf SBCs with configurable firmware, and custom SBCs with custom firmware. However, for new industrial facilities, or for existing facilities that have just undergone a reconfiguration, SBC firmware may need to be modified to improve operations or fix code bugs.
This article will discuss the role of SBCs and why remote debugging is becoming increasingly important in industrial environments. It will then introduce remote debuggers and associated software from MikroElektronika and explain how they can be connected to a Wi-Fi network to remotely debug Arm microcontrollers in most SBCs.
SBCs in industrial computers
Modern industrial automation facilities are under pressure to increase productivity by better process management through greater precision. This can include using high-resolution sensors to provide more accurate data to the control firmware. In addition, actuators such as motors and solenoids can be upgraded to actuators that can move in much finer increments.
Once these higher accuracy and higher resolution sensors and actuators are installed, the control firmware in the SBCs that manage these devices must be modified to take advantage of the increased resolution. If the firmware upgrade can’t be handled by the current SBC, then a new SBC must be installed. In either case, the new firmware will typically be tested and debugged on the bench before being installed in the Industrial Automation facility. After initial tests, the new system is put into operation.
However, for more complex processes the debugging and programming may not end there. In-system operation can reveal issues not discovered during these pre-production tests, and in many cases the only way to optimize the firmware is to perform debugging while the SBC is in use.
New industrial automation facilities can face the same issues. This is especially true for high-performance systems where firmware control loops must be fine-tuned to meet efficiency requirements. Regardless of whether the industrial facility is new or upgraded, downtime is expensive and must be minimized. That means the SBCs must be debugged and programmed in-system.
Debugging industrial embedded systems remotely
Debugging the SBCs used in Industrial Automation systems is no different than debugging any microcontroller-based system. A debugger must be physically connected by cable from the microcontroller’s debug port to a PC running a debug software program. A technician at the PC then examines and debugs the firmware as it is running. This can be time-consuming if many SBCs need to be debugged on-site as the technicians need to travel to each SBC’s physical location. This can be more difficult if some SBCs are in harsh environments, or in physically remote or inaccessible locations. In addition, it’s typical that only a limited number of technicians would be familiar with the custom firmware, requiring those technicians to debug many systems in a short time, complicating the procedure and delaying the process.
The solution is to use remote debuggers that are physically connected to the SBCs but have debugging capabilities provided by a networked PC located elsewhere. Remote debuggers can be plugged into the SBC’s microcontroller debug port while connected to a facility’s network via Wi-Fi. A PC on the same network in a convenient location can be used to access any of the remote debuggers. The technician then has complete debug capability at the remote PC.
To perform this remote debug, engineers can use Mikroe’s CodeGrip, a family of remote debuggers that can connect over Wi-Fi to a remote PC to support programming and debugging of many Arm microcontrollers. The MIKROE-3460 CodeGrip Wi-Fi debugger can be used on most Arm microcontrollers with a JTAG port (Figure 1). It also supports the Arm serial wire output (SWO) single-wire debug port found on most Arm Cortex-M3, Cortex-M4, and Cortex-M7 microcontrollers.
The Mikroe MIKROE-3460 CodeGrip is placed at the physical location of the Arm-based SBC. It has a port to connect to the JTAG or SWO port available on the board connector. It is then temporarily connected to a laptop by USB in order to initially configure the CodeGrip unit for the microcontroller being debugged. For high-performance systems, the CodeGrip unit has a USB-C connector. This is especially useful in cramped situations and saves time and frustration, as unlike previous USB connectors, USB-C connectors don’t have a top or bottom orientation.
The laptop connected to the CodeGrip unit must be running Mikroe’s CodeGrip Suite in order to initially configure the CodeGrip unit. The CodeGrip unit indicates its status by five LEDs (Figure 2). This provides critical status information to an on-site technician that the unit is operating properly without having to connect a laptop. When properly powered, the green power LED will light. During normal CodeGrip unit operation the red active LED will also be illuminated. If the green LED is on and the red LED is off, it can indicate a poor or no connection to the JTAG/SWO port; important information to a local technician that the debug cable may need to be reseated or replaced.
Once connected by USB to a laptop, the CodeGrip unit will indicate a successful connection by illuminating the yellow USB-LINK LED on the unit. The user then runs the CodeGrip Suite to configure the CodeGrip unit over the USB connection.
Configuring CodeGrip
The CodeGrip Suite can often auto-detect the Arm microcontroller on the SBC, but it can also be manually configured with the core type, flash memory size, and RAM configuration. However, not all Arm product families can be easily configured using the same debugger. For STMicroelectronics’ STM32 Arm family, Mikroe provides the MIKROE-3461 CodeGrip unit. NXP Semiconductors’ Kinetis family is supported by the MIKROE-3462 CodeGrip. For all of these, the operation of the CodeGrip unit and CodeGrip Suite are identical.
Once connected and configured, the CodeGrip Suite can perform programming and debugging operations on-site. During any data transfer to the CodeGrip unit, the blue data LED will flash, indicating that data is being transferred between the CodeGrip unit and CodeGrip Suite. This indicates the CodeGrip unit is operating properly and is programming or debugging the SBC.
For remote debugging, the CodeGrip unit can be configured to connect over Wi-Fi to a remote PC that is also running CodeGrip Suite. For security and performance purposes, the Wi-Fi network used to connect to the CodeGrip units should be separate from the other Wi-Fi networks used in the industrial facility. Sending a large .bin or .hex file to the CodeGrip unit over Wi-Fi is the equivalent of downloading a large file to a PC, so it can slow the entire network. If a remote PC successfully connects to the CodeGrip unit, the orange NET-LINK LED on the CodeGrip unit will illuminate, indicating a successful connection. Once the CodeGrip unit is configured, the laptop connected over USB can be disconnected.
The CodeGrip Suite can read, program, and erase the entire flash memory on the target microcontroller. It can also compare the contents of the microcontroller’s flash memory with a source file to verify that the firmware is authentic and has not been tampered with. This can also be useful during a security audit to verify security of the firmware without having to travel to the physical location of each SBC.
The CodeGrip Suite can also perform a hardware reset of the target microcontroller. This can be useful for a malfunctioning SBC or if a security breach is suspected. Normally a reset SBC will run a built-in self-test (BIST) on boot which includes security checks, verifying that the device is operating properly and has not been tampered with.
A powerful feature of the Mikroe CodeGrip unit is that it supports the Arm SWO real-time debug port. The SWO pin streams debug information on the status of the Arm microcontroller and can be used to provide, in real time, status and trace information on firmware operation. Mikroe provides an SWO library with functions that can enhance the debugging capabilities of the CodeGrip Suite (Figure 3). This can allow the microcontroller firmware to be easily monitored and debugged remotely.
SWO messages have three message categories; Info, Warning, and Error. CodeGrip can display any or all of these message categories. Displayed messages are color-coded for easy reference; blue for info, yellow for warning, and red for error. This allows users to quickly decide what needs to be viewed, and also to easily prioritize error messages over warnings and info.
Conclusion
Debugging SBCs in Industrial Automation facilities while in-system can be time-consuming, especially if many SBCs must be programmed and debugged. Further, it is not always practical to visit each individual location. As shown, remote debugging over Wi-Fi using devices like CodeGrip and its associated software saves time while improving productivity.
.){kind=link}