7 Essential Tips for Embedded Motherboard Design and Development

To become a formal embedded motherboard design and development engineer is a challenging process that requires developers to maintain and manage every bit and byte of the system. From a well-defined development cycle to strict implementation and system checks, there are many techniques for developing high-reliability embedded systems. Today, I will introduce 7 easy-to-follow and long-lasting techniques that are very helpful for ensuring that the system runs more reliably and captures abnormal behaviors.

Technique 1 - Fill ROM with known values

Software developers are often a very optimistic group. All they want is for their code to run faithfully and consistently for a long time. Such a situation where a microcontroller jumps out of the application space and executes code in unexpected code spaces is quite rare. However, the chance of this happening is not less than that of cache overflows or incorrect pointer dereferences. It does happen! The behavior of the system after such an event will be uncertain because by default, the memory space is all 0xFF, or the values in the memory area may only be known to God if it has not been written to.

Fortunately, there are quite comprehensive linker or IDE techniques that can be used to help identify such events and recover the system from them. The technique is to use the FILL command to fill unused ROM with a known bit pattern. There are many different possible combinations that can be used to fill unused memory, but if you want to build a more reliable system, the most obvious choice is to place the ISR fault handler in these locations. If the system has some errors, the processor starts executing code outside the program space, triggering the ISR and providing an opportunity to store the processor, registers, and system status before deciding on the correction action. 

Technique 2 - Check the CRC of the application

For embedded engineers, one significant advantage is that our IDE and toolchain can automatically generate the checksum (or verification code) for the application or memory space, allowing us to verify whether the application is intact based on this checksum. Interestingly, in many of these cases, the checksum is only used when loading the program code onto the device.

However, if the CRC or checksum remains in memory, then verifying whether the application is still intact at startup (or even periodically for long-running systems) is an excellent way to ensure that unexpected things do not happen. Now, the probability of a programmed application changing is very low, but considering the billions of microcontrollers delivered each year and the potentially harsh working environment, the chance of a medical instrument application crashing is not zero. More likely is that a defect in the system could cause a flash write or erase in a certain sector, thereby destroying the integrity of the application.

Technique 3 - Perform RAM checks at startup

To build a more reliable and solid system, it is very important to ensure that the system hardware is functioning properly. After all, hardware can fail. (Fortunately, software never fails; it only does what the code tells it to do, whether it is correct or not). Verifying that there are no issues with the internal or external RAM during startup is a good way to ensure that the hardware can operate as expected.

There are many different methods for performing RAM checks, but the common method is to write a known pattern and then wait for a short period before reading it back. The result should be that what is read is what was written. The truth is that in most cases, the RAM check passes, which is the desired outcome. But there is a very small possibility that the check fails, and this provides an excellent opportunity to flag hardware problems for the system.

Technique 4 - Use stack monitor

For many embedded developers, the stack seems to be a rather mysterious force. When strange things start to happen, engineers are finally stumped and start to wonder, perhaps something is happening in the stack. The result is blindly adjusting the size and position of the stack, and so on. But the error is often not related to the stack, but how can one be so sure? After all, how many engineers have actually performed worst-case stack size analysis?

The stack size is statically allocated at compile time, but the stack is used dynamically. As the code executes, variables, return addresses, and other information are constantly stored in the stack. This mechanism causes the stack to grow continuously within the allocated memory. However, this growth sometimes exceeds the capacity limit determined at compile time, leading to the stack corrupting adjacent memory areas' data. One way to absolutely ensure that the stack is functioning properly is to implement a stack monitor, and incorporate it as part of the system's "health-check" code (how many engineers would do this?) 。 The stack monitor creates a buffer area between the stack and the "other" memory regions and fills it with known bit patterns. Then, the monitor continuously monitors whether the pattern has any changes. If the bit pattern changes, it means that the stack has grown too large and is about to push the system into the dark abyss! At this point, the monitor can record the occurrence of events, the system status, and any other useful data for future problem diagnosis.

Most real-time operating systems (RTOS) or microcontroller systems that implement a Memory Protection Unit (MPU) have a stack monitor. Horribly, these features are usually disabled by default or are often intentionally turned off by developers. Searching the internet quickly reveals that many people recommend disabling the stack monitor in real-time operating systems to save 56 bytes of flash memory space, etc., but this is a losing proposition!

Technique 5 - Use MPU

In the past, it was difficult to find a Memory Protection Unit (MPU) in a small and inexpensive microcontroller, but this situation is beginning to change. Now, from high-end to low-end microcontrollers, there are MPUs, and these MPUs provide embedded software developers with an opportunity to significantly improve the robustness of their firmware.

MPUs have gradually been coupled with the operating system to establish memory spaces, where processing is separated, or tasks can execute their code without worrying about being stomped on. If something does happen, the uncontrollable processing will be cancelled, and other protection measures will be executed. Pay attention to microcontrollers with such components; if there are any, make full use of this feature.

Technique 6 - Establish a Strong Watchdog System

One of the most popular implementations of a watchdog (watchdog) is at the point where the watchdog is enabled (a good start), but it can also be where the watchdog is cleared periodically using a periodic timer; the activation of the timer is completely isolated from any conditions in the program. The purpose of using a watchdog is to assist in ensuring that if an error occurs, the watchdog will not be cleared, that is, when the operation is paused, the system will be forced to execute a hardware reset to restore. Using an independent timer from the system activity can keep the watchdog in a cleared state even if the system has failed.

For the integration of application tasks into a watchdog system, embedded board developers need to carefully consider and design. For example, a certain technology may allow each task that runs within a certain period to indicate that it can successfully complete its task. In this case, the watchdog is not cleared, and it is forcibly reset. There are also more advanced technologies, such as using an external watchdog processor, which can be used to monitor how the main processor performs, and vice versa. For a reliable system, establishing a strong watchdog system is very important.

Technique 7 - Avoid Volatile Memory Allocation

Engineers who are not accustomed to working in resource-constrained environments may try to use the features of their programming language, which allow them to use volatile memory allocation. After all, this is a technique often used in calculator systems, where memory is allocated only when necessary. For example, in C development, engineers may tend to use malloc to allocate space on the heap. There is an operation that will be executed once completed, and the allocated memory can be returned using free to allow the heap to be used.

In resource-constrained systems, this can be a disaster! One of the problems with using volatile memory allocation is that errors or improper techniques may lead to memory leaks or memory fragmentation. More information... Penguin Love Club has a long history. When such problems occur, most embedded systems do not have the resources or knowledge to monitor the heap or handle it properly. And when they happen, if the application requests space but there is no available space to meet the request, what will happen?

The problems arising from using volatile memory allocation are very complex and dealing with them can be described as a nightmare! An alternative approach is to directly simplify memory allocation in a static manner. For example, simply create a buffer of 256 bytes in the program instead of requesting such a size of memory buffer through malloc. This allocated memory can remain throughout the lifetime of the entire application and there will be no concerns about heap or memory fragmentation issues.

The above tutorial on embedded motherboard design and development can enable development technicians to obtain better methods for embedded systems. All these technologies are the secrets that allow designers to develop more reliable embedded systems.