Firmware is an integral part of any embedded system. Devices are not just a combination of components. Without instructions, a microcontroller “does not know” how to manage peripheral devices. However, embedded firmware development is not an easy task. It involves not only coding but also extensive testing and debugging. Today, we will discuss the common challenges of embedded firmware programming and their solutions.Any embedded system requires firmware. Embedded systems such as smartwatches, microwave ovens, or TV remote controls have different peripherals. Their operation is managed by control elements (usually microcontrollers). To function properly, microcontrollers need “instructions”. Embedded firmware is the specialized software that controls the operation of microcontrollers.Firmware can also be installed on microprocessors and FPGAs, but in this article, we will only discuss the challenges faced in microcontroller firmware development.You may have also heard the term “embedded software”. This is software designed for specific devices, which differs from typical application software that can run on any computer or smartphone as long as they have the necessary operating system. If we compare embedded firmware and embedded software, we find that software controls the high-level functions of the device, while low-level functions are controlled by firmware.However, the distinction between embedded hardware and software is not always clear. Tasks traditionally controlled by hardware can be handled by software, and vice versa.Devices running embedded software also include fitness trackers, washing machines, calculators, robots, smart toys, medical devices, cars, and more.Embedded firmware development is an essential part of designing embedded systems. We offer a variety of custom firmware development services. Our team has extensive experience handling 8-bit, 16-bit, 32-bit, and 64-bit microcontrollers produced by the most popular manufacturers: Atmel, Nordic Semiconductor, Texas Instruments, STMicroelectronics, Renesas, Silicon Labs, and others. We primarily use the Arm Cortex-M processor core series but are also proficient with other alternatives, including AVR, PIC, and MSP430 microcontrollers. If you already have a device that requires embedded software design, we can handle that as well. If your device needs real-time responses, we will create RTOS-based firmware. If the device only needs to run a series of tasks indefinitely when powered on, we can develop non-OS-based firmware. We can also test, debug, and optimize existing firmware and assist in migrating to new hardware. Please contact our team to discuss your case.Types of Embedded Systems
The complexity and size of firmware vary depending on the device being developed. The traditional classification of embedded systems is based on the performance of the microcontroller used in the system or the performance and functionality of the device.Based on the performance of the microcontroller, embedded systems can be classified into the following types:– Small systems (using 8-bit or 16-bit microcontrollers);– Medium systems (using 16-bit or 32-bit microcontrollers);– Complex systems (using 32-bit or 64-bit microcontrollers).According to performance and functionality, embedded systems can be divided into four types:Real-time embedded systemsThese are designed to output signals within specific time intervals. Therefore, they can provide real-time or near-real-time responses, which is why they need to be based on real-time firmware. These systems are primarily used in time-critical fields: automotive electronics, healthcare, military equipment, traffic control, etc.Standalone embedded systemsThese systems can operate independently without a host system (computer). They only receive input signals, process the signals, and provide output. Washing machines, calculators, or MP3 players are typical examples of standalone embedded systems.Networked systemsThese embedded systems are connected to wired or wireless networks. Through this connection, they communicate with embedded servers to access resources and provide output to connected devices. An ATM is an example of a networked embedded system.Mobile systemsThese systems are used in small portable devices such as smartphones, tablets, and digital cameras. These systems overlap with standalone embedded systems. Essentially, these are portable standalone embedded systems. All these systems require embedded software to function properly. Integra Sources has developed all these systems and knows how to tackle the typical challenges of embedded system software development.Typical Challenges in Embedded Firmware DevelopmentSecurity IssuesFirmware can be a vector for threats in embedded systems. Programmers often focus on securing applications and operating systems. However, the first code executed on a device is the firmware. If hackers gain access to this code, the entire system is at risk.In 2011, security researcher Charlie Miller discovered a vulnerability in the MacBook battery. He was able to control the firmware of the microcontroller managing the battery. As a result, Miller could infect the computer through the firmware, even causing the battery to overheat and catch fire.Intellectual property protection is another common security issue in firmware programming. One of our projects illustrates typical security measures that programmers can use. When we developed a Bluetooth music pedal for hands-free sheet music turning, we had to ensure the security of its firmware updates. Here, using encryption for wireless updates is a standard practice.In this project, we used the nRF51822 with BLE 4.0 support and Cortex-M0 core as the MCU. For encryption, the team used the nRF Util development tool, which can generate encryption keys and device firmware update (DFU) packages. This tool allows you to encrypt the package before sending it wirelessly to the device.Another project of ours involved embedded firmware and software development for a battery management system. Security was a significant concern for the client. Our team provided two levels of protection.As the first level of protection, our team used encryption technology. The system has multiple PCBs with microcontrollers, each requiring regular firmware updates. To initiate this process, someone receives the update image—usually via email. At this point, the file is susceptible to theft. To ensure the file content cannot be copied, our team used the AES-256 algorithm to encrypt the image file. Once the device receives the file, it decrypts the content before installation.As the second level of protection, the team utilized digital signatures to protect the image file. When the hardware receives the update, it checks the signature to ensure the update comes from Integra Sources. If the signature is incorrect or missing, the device will not install it.This measure is commonly used to protect devices from potential hacking attempts. Even if hackers successfully crack the encryption code, the system will ignore the update file due to the lack of a correct signature.Insufficient MemoryEmbedded development has limited available resources, and firmware is no exception. As mentioned earlier, some embedded systems can be very small: TV remote controls, network cameras, MP3 players. This size, in turn, limits battery capacity, available processing power, or memory size. Moreover, as devices become smaller, consumers demand more functionality. Our custom firmware development services will help you address this contradiction.A specific issue arising from design constraints is the size of available memory.Typically, engineers try to find a workaround during the design phase of embedded system development. Designers can roughly estimate how much memory the device will need and know what size components can be used. Additionally, our team will try to choose microcontrollers or microprocessors with some memory or processing capacity headroom. We can estimate these parameters based on the number and complexity of the functions to be implemented.However, these estimates may not be accurate, or requirements may change during the prototyping phase. Therefore, developers may have to optimize the firmware to fit the available memory size.Our team encountered this issue while developing hardware and firmware for a graphic calculator. The firmware of this calculator has an input interpreter for processing mathematical formulas. The device also uses an embedded language. The latter essentially uses the same syntax as the interpreter for expression evaluation. In other words, both functions are accomplished by very similar code.As a result, the firmware team added the unique features from the interpreter into the embedded language and removed the interpreter. This way, we saved about 100 KB in the microcontroller’s flash memory.
Another method to optimize firmware memory size is to use appropriate data types. If you need to store numbers from 0 to 100, a 1-byte data type is sufficient. However, if the firmware uses a 4-byte data type to store the same number, memory usage becomes inefficient.In the aforementioned project, we initially used a double data type (8 bytes). It is more precise than many other types. However, the calculator does not require such precision, so the team decided to switch to float (4 bytes). Although float is not as precise as double, it requires half the memory space.
Both constants and variables can use lighter data types. If it is determined that a variable’s value will not exceed 100, there is no need to use a heavier data type.Energy EfficiencyWhen embedded firmware developers deal with portable devices, energy efficiency becomes another challenge. It is essential to understand what functions the device needs to perform and which components can meet these requirements before starting development. Please contact our team, and we will provide you with advice.The energy consumption of a microcontroller consists of two parts: the processor core and peripherals. By optimizing the operation of these two components, the energy efficiency of the device can be improved.An obvious way to reduce the energy consumption of the processor core is to decrease the number of instructions it processes. In this case, optimizing the code can be helpful.Another method is to use the sleep mode of the microcontroller. Typically, we do not need the processor core to be active all the time. Therefore, when data processing is not required, we let it enter sleep mode. The core remains in this mode until an external event occurs (e.g., a timer interrupt).The firmware of the graphic calculator we created consists of a cycle. In each cycle, the core polls buttons. It polls 30 times per second, taking only a few microseconds. If no key is detected, the core remains in sleep mode.Thus, the microcontroller’s power consumption in polling mode is about 5 mA. In contrast, in busy-wait mode, the microcontroller consumes about 80 mA.Firmware developers also apply the same approach to peripherals—turning them off when not needed. Another project we were involved in also used battery power. Due to the need for extensive data packet exchanges, the device regularly outputs logs via UART. However, when no data exchange occurs, the device remains idle. To minimize the energy consumption of UART, we programmed it to turn off when not needed.
Of course, this approach only applies to output. Since the processor core executes instructions based on input signals, turning off input signals is usually not a good idea. In this case, UART is used only for signal output.Our team also adopted a similar approach when helping to create personnel and asset tracking devices. It uses BLE 5.0 to send and receive data packets every 7.5 milliseconds. During the connection, BLE’s power consumption peaks. One of our goals was to minimize power consumption without affecting channel capacity.Through firmware, we programmed the device to buffer data packets. This way, we were able to triple the connection interval. During the interval, BLE’s power consumption is at its lowest. Therefore, longer intervals can reduce the device’s power consumption.
Debugging ChallengesDebugging is an inevitable part of embedded firmware and embedded software development services, especially when designing complex devices. To find errors in the code, programmers use debugging tools. These tools allow for step-by-step execution of the code and detection of the parts where the program crashes. However, some devices do not have compatible debugging tools. Arduino is an example of such devices.In this case, it is necessary to monitor the program’s execution by printing the required values, code lines, or text (e.g., outputting data via UART) in the console. These code lines are placed in the code segments that may contain errors.If values, code lines, or text are printed, it indicates that the code has executed as expected. If a line is not printed or the value changes, it indicates that there was an issue in the previous step. If there is no console, LED lights can also be used to signal.It can be said that this process is very tedious and time-consuming compared to using debugging tools, as errors must be detected manually. But sometimes, firmware developers have no choice.The firmware development process ends with the debugging configuration of the firmware. In addition to the code required for the microcontroller, it also contains debugging information. Through this, you can view the code in the debugging tool and step through to find errors.However, before downloading the firmware to the device, the debugging information is removed for optimization. This version of the firmware is called the release configuration. Of course, at this stage, the code is checked repeatedly for errors, so there should be no issues after installation. Problems may arise when updating the firmware.In this case, the device starts to malfunction after the update, indicating that the code contains errors. Programmers can no longer use debugging tools and must resort to the aforementioned methods.Updates and Over-the-Air Downloads
Whenever new errors are discovered or users request new features, developers must update the firmware. This can become another firmware design issue, especially with over-the-air (OTA) updates.Updating a simple device is very straightforward. However, complex systems, especially IoT devices, require more resources. Programmers must deal with a series of issues: insufficient memory, bandwidth limitations, version management, and of course, security issues.One common problem is interruptions. Simple devices with limited memory capacity must rewrite firmware immediately after receiving data. If any interruption occurs, the firmware can become corrupted: for example, if power is lost before installation is complete.In the worst-case scenario, the device may become bricked and irreparable. If the device has a bootloader, the firmware can be reinstalled. However, when using OTA updates, interruptions can be frequent. This issue can often be resolved by using backup memory.When our team was involved in a smart home project, it was clear that the device would be updated wirelessly. Interruptions causing stalls or failures are unacceptable. Therefore, the team provided the system with backup memory.In this case, the update file is first downloaded to the backup memory. It can be a file system or a flash area. Then, the device runs a data integrity check to ensure that no bytes were lost or changed during transmission. Only then is the update installed. Thus, interruptions do not have severe consequences.ConclusionAny embedded system requires firmware to perform its functions. Whether it is a small device or a complex system, its functionality and performance largely depend on the firmware. Moreover, the quality of embedded software determines the stability of the device.Developers often encounter various design constraints when developing firmware. The size, power supply, cost, and other factors of the device determine what kind of microcontroller can be used. This, in turn, leads to other issues such as insufficient memory or energy efficiency problems.Another typical challenge is related to firmware updates. OTA updates lack stability, leading to interruptions in data transmission, ultimately resulting in data corruption. If updates are installed directly without first loading them into backup memory, it can lead to device damage. Security is another critical issue that needs to be addressed, as firmware can become a vector for threats in embedded systems.Finally, developers often spend a significant amount of time debugging. This is why many companies outsource embedded firmware development to electronic design firms.