Intel skylake sixth generation microprocessor eight main features

Become a full embedded motherboard development engineer. It is a laborious process that requires the developer to maintain and manage every bit and byte of the system. There are many techniques for developing highly reliable embedded systems, from well-regulated development cycles to rigorous execution and system review. Here are seven easy to follow and long-lasting tips that can go a long way toward making your system run more reliably and catching unusual behavior.

Tip 1 - Fill the ROM with known values

Software developers tend to be very optimistic people, just keep their code running faithfully for a long time, that's all. It seems to be fairly rare for a microcontroller to jump out of the application space and execute in an unintended code space. However, this is no less likely to happen than a cache overflow or an error pointer losing a reference. It does happen! The behavior of the system after this happens will be uncertain because the memory space is all 0xFF by default, or because the memory area is usually not written, the value in it may be known only to God.

However, there are fairly well-developed linker or IDE techniques that can be used to help identify such events and recover systems from them. The trick is to use the FILL command to fill a known bit pattern without ROM. There are many different possible combinations you can use to populate unused memory, but if you want to build a more reliable system, the most obvious choice is to place an ISR fault handler in these locations. If something goes wrong with the system and the processor starts executing code outside of program space, the ISR triggers and provides an opportunity to store processor, register, and system state before deciding on corrective action.

Tip 2 - Check your application's CRC

A great benefit for embedded engineers is that our IDE and toolchain can automatically generate an application or memory space Checksum (Checksum) against which the application is validated. 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 is kept in memory, verifying that the application is still sound at startup (or even periodically verifying a long-running system) is an excellent way to ensure that the unexpected doesn't happen. The chance of a programmed application changing is now small, but given the billions of microcontrollers delivered each year and the potentially hostile work environment, the chance of an application crashing is not zero. More likely, a defect in the system could cause flash writes or flash erases to occur in a sector, thus compromising the integrity of the application.

Tip 3 - Perform a RAM check at startup

In order to build a more reliable and robust system, it is important to ensure that the system hardware is working properly. Hardware can fail, after all. (Fortunately, software never breaks. Software does what the code tells it to do, whether it's right or wrong.) Verifying that there are no problems internally or externally with RAM at boot time is a good way to ensure that the hardware works as expected.

There are many different ways to perform RAM checks, but a common approach is to write to a known pattern, then wait a short period of time before reading back. The result should be that what you read is what you write. The truth is that RAM checks pass in most cases, which is what we want. However, there is a very small chance that the check will fail, which provides an excellent opportunity for the system to flag a hardware problem.

Tip 4 - Use the stack monitor

To many embedded developers, the stack seems to be a rather mysterious force. When strange things start to happen, the engineers are finally stumped, and they start to think, maybe there's something going on in the stack. The result is a blind adjustment of stack size and position, and so on. But the error is often stack independent, but how can you be so sure? After all, how many engineers actually perform 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, returned addresses, and other information needed by the application are continually stored on the stack. This mechanism causes the stack to grow in its allocated memory. However, this growth can sometimes exceed the capacity limits determined at compile time, causing the stack to destroy data in adjacent memory regions.

One way to absolutely ensure that the stack is working properly is to implement a stack monitor as part of your system's "health" code (how many engineers do that?). . The stack monitor creates a buffer region between the stack and the "other" memory region and populates the known bit patterns. The monitor then continuously monitors the pattern for any changes. If the bit pattern changes, it means the stack has grown too large and is about to send the system into a dark hell! At this point the monitor can record the occurrence of events, the state of the system, and any other useful data for later problem diagnosis.

Stack monitors are 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 turned off by developers. A quick search on the web reveals that many people recommend turning off the stack monitor in real-time operating systems to save 56 bytes of flash memory space, etc., which is not worth the trouble!

Tip 5 - Use an MPU

In the past, it was hard to find a memory protection unit (MPU) in a small, inexpensive microcontroller, but that's starting to change. There are already MPUs in microcontrollers from high to low end, and these MPUs provide embedded software developers with a machine that can greatly improve the robustness of their firmware

The MPU has gradually been coupled to the operating system in order to establish memory Spaces where processing is separated or tasks can execute their code without fear of being stomped on. If something does happen, uncontrolled processing is canceled and other protective measures are implemented. Be on the lookout for microcontrollers with such components, and if so, take advantage of this feature.

Tip 6 - Build a strong watchdog system

One of the always favorite watchdog implementations you'll often find is where the watchdog is enabled (which is a good start), but also where the watchdog can be cleared with a periodic timer; Timer enablement is completely isolated from anything that occurs in the program. The purpose of using a watchdog is to help ensure that if an error occurs, the watchdog is not zeroed out, that is, when work is halted, the system is forced to perform a hardware reset in order to recover. Using a timer that is independent of system activity allows the watchdog to stay clear even if the system has failed.

Embedded developers need to carefully consider and design how application tasks are integrated into watchdog systems. For example, one technique might allow each task that runs for a certain period of time to indicate that it can successfully complete its task. In this event, the watchdog is not zeroed out and is forced to reset. Some more advanced techniques, such as the use of an external watchdog processor, can be used to monitor how the main processor is performing and vice versa. A strong watchdog system is important for a reliable system.

Tip 7 - Avoid volatile memory allocation

Engineers who are not used to working in a resource-constrained environment may try to use features of their programming language that allow 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 might prefer to use malloc to allocate space on the heap. An operation is executed, and once completed, the allocated memory can be returned using free for heap use.

In resource-constrained systems, this can be a disaster! One of the problems with using volatile memory allocation is that faulty or improper techniques can lead to memory leaks or memory fragmentation. If these problems occur, most embedded systems do not have the resources or knowledge to monitor the heap or properly handle it. And when they do, what happens if the application makes a request for space, but no requested space is available?

The problems that arise from using volatile memory allocation are complex and can be a nightmare to deal with properly! An alternative is to simply allocate memory in a static manner. For example, instead of malloc requesting a memory buffer of that size, you can simply create a buffer in your program that is 256 bytes long. This allocated memory can be held throughout the application lifecycle without concerns about heap or memory fragmentation.

The above embedded development tutorial can give technical developers access to better embedded systems. All of these techniques are secrets that allow designers to develop more reliable embedded systems.