Multiple prompts for embedded PCB main board
It is a diffICult process to become a formal design and development engineer of embedded PCB motherboard, requiring developers to maintain and manage every bit and byte group of the system From standard development cycle to strict implementation and system inspection, there are many technologies for developing high reliability embedded systems Today, I will introduce 7 kinds of PCB technologies that are easy to operate and can be used for a long time They are very helpful in ensuring more reliable system operation and catching abnormal behavior
Software developers are usually a very optimistic group, as long as their code runs faithfully for a long time. It seems very rare for a microcontroller to jump out of application space and run in unexpected code space. However, this is no less likely to happen than a buffer overflow or a missing reference to the wrong pointer. It will happen! After this happens, the system's behavior 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 by God.
However, you can use fairly complete linker or IDE skills to help identify such events and recover the system from them. The trick is to use the FILL command to fill unused ROMs with known bit patterns. Many different possible combinations can be used to populate unused memory, but if you want to build a more reliable system, the most obvious option is to place ISR fault handlers in these locations. If a system problem occurs and the processor begins to execute code outside of program space, it triggers the ISR and provides an opportunity to store the processor, registers, and system state before deciding on corrective action.
Circuit board

One of the advantages of embedded engineers is that our IDE and tool chain can automatically generate application or memory space checksums to verify whether the application is complete. Interestingly, in many cases, checksums are used only when code is loaded into the device.
However, if the CRC or checksum is stored in memory, it is a good way to ensure that the application is still intact at startup (even periodically for long running systems). Today, the possibility of changing the programming application is very SMAll, but considering the billions of microcontrollers delivered every year and the potentially harsh working environment, the possibility of medical device application crash is not zero. More likely, a defect in the system may cause flash writing or flash erasure in a sector, thus damaging the integrity of the application.
Perform RAM check at startup
In order to establish a more reliable and reliable system, it is very important to ensure that the system hardware works normally. After all, the hardware will fail. (Fortunately, software never fails. It only does what the code wants it to do, whether right or wrong.). Verifying that there are no problems with internal or external RAM during startup is a good way to ensure that the hardware can run as expected.
There are many different ways to perform RAM checking, but the common way is to write a known pattern and then wait for a short period of time before reading it back. The result should be that what you read is what you write. The fact is that in most cases, the RAM check is passed, which is the result we want. However, the probability of failure is very low, which provides an excellent opportunity for the system to teach hardware problems.
Using the Stack Monitor
For many embedded developers, the stack seems to be a rather mysterious force. When strange things began to happen, the engineers were finally baffLED and began to think about what might happen in the stack. The result is blindly adjusting the size and position of the stack. But an error is usually stack independent, but how can it be so sure? After all, how many engineers actually perform a worst-case stack size analysis?
The stack size is statically allocated at compile time, but the stack is used as a dynamic pipe. Variables, return addresses, and other information required by the application are continuously stored on the stack when the code is executed. This mechanism keeps the stack growing 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 regions.
One way to absolutely ensure that the stack works is to implement the stack monitor as part of the system's "healthy" code (how many engineers do this?). The stack monitor creates a buffer between the stack and the "other" memory area and fills it with a known bit pattern. The monitor then continuously monitors the mode for any changes. If the bit pattern changes, it means that the stack grows too much, and the system will be pushed into hell! At this point, 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 RTOs or microcontroller systems that implement memory protection units (MPUs). Terrible is that these functions are turned off by default, or are often deliberately turned off by developers. A quick search on the Internet found that many people suggested turning off the stack monitor in the instant operating system to save 56 bytes of flash memory space. It's not worth it!
Use MPU
In the past, it was difficult to find a memory protection unit (MPU) in a small and cache microcontroller, but this situation has begun to change Now, microcontrollers from high-end to low-end have microprocessors. These microprocessors provide embedded PCB software developers with the opportunity to greatly improve the robustness of their firmware
In order to create a memory space, the MPU is gradually coupled with the operating system. In this memory space, processing is separated, or tasks can execute their code without fear of being trampled. If anything happens, the uncontrolled treatment will be cancelled and other protective measures will be implemented. Please note that microcontrollers with such components, if any, should make more use of their features.
Establish a strong supervision system
You will often find that one of your favorite watchdog implementations is to enable the watchdog position (this is a good start), but you can also use a regular timer to clear the watchdog position; The start of the timer is completely isolated from anything that happens 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 to resume. With a timer that is independent of system activity, the watchdog can remain cleared even if the system fails.
How to integrate the application tasks into the watchdog system, embedded PCB board developers need to carefully consider and design. For example, there is a technology that allows each task running in a specific time period to instruct them to successfully complete their task. In this case, the watchdog will not be cleared, but will be forcibly reset. There are also some more advanced technologies, such as the use of an external watchdog processor, which can be used to monitor the behavior of the main PCB processor, 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 resource limited environments may try to use the functions of their programming language, which allows them to use volatile PCB memory allocation After all, this is a PCB technology commonly used in small abacus system In an abacus system, memory is allocated only when necessary For example, when developing in C, engineers may prefer to use malloc to allocate space on the heap An operation will be performed Once done, you can use free to return the memory allocated to the heap