Embedded development system Seven tips, easy to operate and can be used for a long time Oh!

Becoming a formal embedded development engineer is an arduous process. There are many techniques for developing high-reliability embedded systems from a well-developed development cycle to rigorous execution and system inspection. This article describes 7 easy-to-use and long-running techniques that can be helpful in ensuring that your system runs more reliably and captures abnormal behavior.

Tip 1: Populate the ROM with known values

Software developers tend to be a very optimistic bunch of people, just let their code run faithfully for a long time, that's all. It seems quite rare that a microcontroller would jump out of the application space and execute it in unintended code space. However, the chances of this happening are not less than the cache overflow or the error pointer losing reference. It does happen! The behavior of the system after this happens will be indeterminate, because the memory space is 0xFF by default, or because the memory area is not usually written, the value of which may only be known by God. More exciting content can also pay attention to the Huaqing vision Oh!

However, a fairly complete linker or IDE technique can be used to help identify and recover from such events. The trick is to use the Fill command to populate the unused ROM with known bit patterns. There are many different possible combinations to fill unused memory, but if you want to build a more reliable system, the most obvious option is to place the ISR fault handler in those locations. If something goes wrong with the system, the processor starts executing code outside the program space, triggering the ISR and providing the opportunity to store the processor, register, and System state before deciding on the corrective action.

Tip 2: Check the application's CRC

A big benefit for embedded engineers is that our IDE and Toolchain can automatically generate application or memory space checksums (Checksum) to verify that the application is intact based on this checksum. Interestingly, in many of these cases, checksums are only used when the program code is loaded into the device.

However, if the CRC or checksum remains in memory, then verifying that 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 change is small, but considering the billions of microcontrollers delivered each year and the potentially harsh work environment, the chances of an application crash are not zero. More likely, a flaw in the system could result in a flash write or flash erase in one sector, which could disrupt the integrity of the application. More exciting content can also pay attention to the Huaqing vision Oh!

Tip 3: Perform a RAM check at startup

In order to build a more reliable and solid system, it is important to ensure that the system hardware is working properly. After all, the hardware will fail (fortunately, the software will never fail, the software can only do what the code wants it to do, whether it's right or wrong). Validating the internal or external ram at startup is a good way to ensure that the hardware works as expected.

There are many different ways to perform a ram check, but the common approach is to write a known pattern and wait for a short period of time to read back. The result should be read or write. The truth is, in most cases the Ram check is passed, and that's the result we want. But there is a very small possibility that the check does not pass, which provides an excellent opportunity for the system to identify hardware problems.

Tip 4: Use the stack monitor

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

The stack size is statically allocated at compile time, but the stack is used in a dynamic manner. As the code executes, the variables, addresses, and other information that the application needs are constantly stored in 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 regions.

One way to absolutely ensure that the stack is working is to implement the stack monitor as part of the system's "Health" code (how many engineers would do that?). ）。 The stack monitor creates a buffer field between the stack and the "other" memory area and populates the known bit pattern. The monitor will then constantly monitor for any changes in the pattern. If the pattern changes, it means that the stack is growing too much and is about to push the system to dark hell! At this point the monitor can record the occurrence of the event, the system status, and any other useful data for later diagnosis of the problem.

A stack monitor is available in most real-time operating systems (RTOS) or microcontroller systems that implement a Memory protection Unit (MPU). The scary thing is that these features are turned off by default, or are often intentionally closed by the developer. A quick search on the web reveals that many people recommend shutting down the stack monitor in the real-time operating system to save 56 bytes of flash space. Wait, this is not worth the candle! More exciting content can also pay attention to the Huaqing vision Oh!

Tip 5: Use MPU

In the past, it was difficult to find a Memory protection Unit (MPU) in a small, inexpensive microcontroller, but this situation has begun to change. Now the MPU is already available from high-end to low-end microcontrollers, which provide an opportunity for embedded software developers to significantly improve their firmware (firmware) robustness (robustness).

MPU has gradually been 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 fear of being stomped on. If something really happens, uncontrolled handling will be canceled and other protections will be enforced. Please be aware of the microcontroller with this component, and if so, take advantage of this feature.

Tip 6: Build a powerful watchdog system

What you'll often find is that a always-favorite watchdog (watchdog) implementation is where the watchdog is enabled (this is a good start), but it can also be used to clear 0 of the watchdog with a recurring timer, and the timer is completely isolated from any situation that occurs in the program. The purpose of the watchdog is to help ensure that if an error occurs, the watchdog will not be zeroed out, i.e. when the work is paused, the system will be forced to perform a hardware reset (hardware reset) in order to restore it. Using a timer independent of the system activity allows the watchdog to remain zeroed even if the system has failed.

Embedded developers need to carefully consider and design how application tasks are integrated into the watchdog system. For example, there may be a technique that allows each task to run within a certain period of time to indicate that they can successfully complete their task. In this event, the watchdog is not zeroed and forced to be reset. There are also more advanced technologies, such as the use of an external watchdog processor, which can be used to monitor how the main processor behaves and vice versa.

For a reliable system, it is important to build a robust watchdog system. Because there are too many technologies, it is difficult to fully cover these paragraphs, but in response to this issue, the author will publish the relevant articles in the future.

Tip 7: Avoid volatile memory allocations

Engineers who are not accustomed to working in resource-constrained environments may try to use the features of their programming language, which allows them to use volatile memory allocations. After all, this is a technique that is often used in a calculator system where the memory is allocated only if necessary. For example, when developing with C, an engineer might prefer to use malloc to allocate space on the heap (heap). One operation executes, and once done, you can use free to return the allocated memory for use by the heap.

In a resource-constrained system, this could be a disaster! One of the problems with volatile memory allocation is that errors or improper techniques can cause memory leaks or memory fragmentation. If these problems occur, most embedded systems do not have the resources or knowledge to monitor the heap or to properly handle it. And when they happen, what happens if the application asks for space, but does not have the requested space to use?

The problem with the use of volatile memory allocation is complicated, so it is a nightmare to deal with these problems properly. An alternative approach is to simplify the allocation of memory directly, in a static manner. For example, simply create a buffer with a size of 256 bytes long in the program, rather than a memory buffer of this size through malloc requests. This allocated memory can be maintained throughout the lifetime of the application without any concerns about heap or memory fragmentation issues.

Conclusion

All of these technologies are the secret to enabling designers to develop more reliable embedded systems.

Embedded development system Seven tips, easy to operate and can be used for a long time Oh!