Software developers are usually a very optimistic group of people. All they need is to ensure that their code runs faithfully and for a long time. That's all. The situation where a microcontroller jumps out of the application space and executes code in an unexpected code space seems to be quite rare. However, the chance of this happening is no less than that of cache overflow or incorrect pointer dereferencing. It definitely will happen! The behavior of the system after such a situation occurs will be uncertain because by default the memory space is all 0xFF, or because the memory area is usually not written to, the values within it may only be known to God. 

However, 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 involves using the FILL command to fill unused ROM with a known bit pattern. To fill unused memory, there are many different possible combinations that can be used, but if one wants to build a more reliable system, the most obvious choice is to place the ISR fault handler in these locations. If the system experiences certain errors, the processor starts executing code outside the program space, which will trigger the ISR and provide an opportunity to store the processor, registers, and system status before deciding on the corrective action.

For embedded engineers, one significant advantage is that our IDE and toolchain can automatically generate application or memory space checksums, 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 the program code is loaded onto the device. 

However, if the CRC or checksum is kept in memory, then verifying whether the application is still intact upon startup (or even periodically for long-running systems) is an excellent way to ensure that unexpected situations do not occur. 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 sector in the flash memory to undergo flash write or flash erase, thereby destroying the integrity of the application.

In order to establish a more reliable and solid system, it is crucial to ensure that the system hardware is functioning properly. After all, hardware can fail. (Fortunately, software never fails; it simply does what the code instructs it to do, whether it is correct or incorrect). 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 available for performing RAM checks, but the commonly used method is to write a known pattern, then wait for a short period of time before reading it back. The result should be that what is read is exactly what was written. The truth is that in most cases the RAM check passes, which is the result we want. However, there is a very small possibility that the check fails, and in such cases it provides an excellent opportunity to indicate hardware problems for the system.

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

The stack size is statically allocated during compilation, but the stack is used dynamically. As the code executes, the variables needed by the application, return addresses, and other information are continuously stored in the stack. This mechanism causes the stack to continuously grow within the allocated memory. However, this growth sometimes exceeds the capacity limit determined at compile time, resulting in the stack damaging the data in adjacent memory areas. 

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 will create a buffer area between the stack and the "other" memory area, and fill it with known bit patterns. Then the monitor will continuously monitor whether there are any changes in the pattern. 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, which can be used for problem diagnosis in the future. 

Most real-time operating systems (RTOS) or microcontroller systems that implement memory protection units (MPU) all have stack monitors. The scary thing is that these functions are usually in a disabled state by default, or they are often deliberately turned off by developers. A quick search on the internet will reveal that many people recommend disabling the stack monitors in real-time operating systems to save 56 bytes of flash memory space, etc. But this is a losing proposition!

In the past, it was difficult to find memory protection units (MPUs) in small and inexpensive microcontrollers. However, this situation is beginning to change. Now, MPUs are available in microcontrollers ranging from high-end to low-end, and these MPUs provide embedded software developers with an opportunity to significantly enhance the robustness of their firmware. 

The MPU has gradually been coupled with the operating system to establish memory space, where the processing is separated. Or tasks can execute their code without worrying about being overwritten. If something really happens, the uncontrolled processing will be cancelled and other protection measures will be executed. Please pay attention to microcontrollers with such components. If there are any, please make full use of this feature.

One of the most commonly used and favored implementations of a watchdog is to enable it at the point where it is needed (this is a good start), but it can also be reset by a periodic timer; the activation of the timer is completely isolated from any conditions occurring in the program. The purpose of using a watchdog is to assist in ensuring that if an error occurs, the watchdog will not be reset, that is, when the operation is paused, the system will be forced to perform a hardware reset (hardware reset) in order to recover. Using a timer independent of system activities can keep the watchdog in a reset state, even if the system has failed. 

Embedded motherboard developers need to carefully consider and design how application tasks can be integrated into the watchdog system. For instance, there is a technology that enables each task running within a certain period to indicate that it can successfully complete its task. In this case, the watchdog is not reset and is forcibly reinitialized. 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 robust watchdog system is very important.

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

In resource-constrained systems, this could 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 Long-term Zero needs to be a strong umbrella. If these problems occur, most embedded systems do not have the resources or knowledge to monitor the heap or handle it properly. And when they do occur, if the application requests space but there is no available space to meet the request, what happens? 

The problems arising from the use of volatile memory allocation are quite complex and dealing with them properly can be described as a nightmare! An alternative approach is to directly simplify the memory allocation in a static manner. For instance, 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.