PCB Technical - Multiple tips for embedded PCB motherboards

Becoming a formal embedded PCB motherboard design and development engineer is a difficult process, requiring developers to maintain and manage every bit and byte of the system. From a well-regulated development cycle to strict implementation and system inspections, there are many technologies for developing high-reliability embedded systems. Today, I will introduce 7 PCB techniques that are easy to operate and can be used for a long time. They are very helpful to ensure that the system runs more reliably and catch abnormal behaviors.

Software developers are often a very optimistic group of people, as long as their code runs faithfully for a long time, nothing more. It seems quite rare for a microcontroller to jump out of the application space and execute in an unexpected code space. However, the chance of this happening is no less than a buffer overflow or a wrong pointer losing reference. It will happen! The behavior of the system after this happens is uncertain, because the memory space is 0xFF by default, or because the memory area is usually not written, the value may only be known to God.

But there are quite complete linker or IDE skills that can be used to help identify such events and recover the system from them. The trick is to use the FILL command to fill the unused ROM with a known bit pattern. To fill unused memory, there are many different possible combinations that can be used, but if you want to build a more reliable system, the most obvious choice is to place ISR fault handlers in these locations. If something goes wrong in the system and the processor starts to execute code outside of the program space, it will trigger the ISR and provide an opportunity to store the processor, registers, and system state before deciding on corrective actions.

A great advantage for embedded engineers is that our IDE and tool chain can automatically generate application or memory space checksum (Checksum), thereby verifying 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 into the device.

However, if the CRC or checksum is kept in memory, then verifying that the application is still intact at startup (or even periodically for a long-running system) is an excellent way to ensure that unexpected things do not happen. Nowadays, the probability of a programmed application changing is very small, 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, a defect in the system may cause flash write or flash erase in a certain sector, thereby destroying the integrity of the application.

Perform RAM check at startup

In order to build a more reliable and solid system, it is very important to ensure that the system hardware works normally. After all, the hardware will fail. (Fortunately, the software never fails, the software will only do what the code wants it to do, whether it's right or wrong). Verifying that there is no problem with the internal or external RAM at 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 a short period of time before reading it back. The result should be that what you read is what you write. The truth is that in most cases the RAM check is passed, which is the result we want. However, there is a very small possibility that the check will not pass, which provides an excellent opportunity for the system to indicate a hardware problem.

Use stack monitor

For many embedded developers, the stack seems to be a rather mysterious force. When strange things started to happen, the engineers were finally stumped, and they began to think about what might be happening in the stack. The result is to blindly adjust the size and position of the stack and so on. But the error is often not related to the stack, but how can it be so sure? After all, how many engineers have actually performed a worst-case stack size analysis?

The stack size is statically allocated at compile time, but the stack is used in a dynamic way. As the code is executed, the variables, return addresses, and other information needed by the application are continuously stored on the stack. This mechanism causes the stack to grow continuously in its allocated memory. However, this growth sometimes exceeds the capacity limit determined at compile time, causing the stack to destroy data in adjacent memory areas.

One way to absolutely ensure that the stack is working properly is to implement a stack monitor as part of the system's "health" code (how many engineers do this?). The stack monitor creates a buffer area between the stack and the "other" memory area and fills it with a known bit pattern. 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 much, and the system is about to be pushed to the dark hell! At this time, the monitor can record the occurrence of events, system status, and any other useful data for future problem diagnosis.

Stack monitors are provided in most real-time operating systems (RTOS) or microcontroller systems that implement a memory protection unit (MPU). The scary thing is that these functions are turned off by default, or are often turned off deliberately by developers. A quick search on the Internet reveals that many people suggest turning off the stack monitor in the real-time operating system to save 56 bytes of flash memory space, etc. This is not worth the gain!

Use MPU

In the past, it was difficult to find a memory protection unit (MPU) in a small and cheap microcontroller, but this situation has begun to change. Now microcontrollers from high-end to low-end already have MPUs, and these MPUs provide embedded PCB software developers with an opportunity to greatly improve the robustness of their firmware.

MPU has been gradually coupled with the operating system in order to establish a memory space, where the processing is separated, or the task can execute its code without worrying about being stomped on. If something happens, the uncontrolled processing will be cancelled and other protective measures will be implemented. Please pay attention to the microcontroller with this kind of component, if there is, please make more use of its characteristic.

Build a powerful watchdog system

One of the always favorite watchdog implementations you will often find is where the watchdog is enabled (this is a good start), but you can also use a periodic timer to Where the watchdog is cleared; the activation of the timer is completely isolated from any situation that occurs in the program. The purpose of using the watchdog is to help ensure that if an error occurs, the watchdog will not be cleared, that is, when the work is suspended, the system will be forced to perform a hardware reset for recovery. Using a timer independent of system activity allows the watchdog to remain cleared even if the system has failed.

How to integrate application tasks into the watchdog system, embedded PCB motherboard developers need to carefully consider and design. For example, there is a technique that may allow each task that runs within a certain period of time to indicate that they can successfully complete its task. In this event, the watchdog is not cleared and is forced to be reset. There are also some more advanced technologies, such as the use of an external watchdog processor, which can be used to monitor how the main PCB processor behaves, and vice versa. For a reliable system, it is very important to establish a strong watchdog system.

Avoid volatile memory allocation

Engineers who are not used to working in an environment with limited resources may try to use the features of their programming language, which allows them to use volatile PCB memory allocation. After all, this is a PCB technology often used in calculator systems. In calculator systems, 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. Once completed, you can use free to return the allocated memory for the use of the heap.