Embedded system development process and seven tips for improving reliability

At present, embedded system development and application is very extensive, and it has applications in many fields, and the technology is updated very quickly.

The embedded system is application-centric, based on computer technology, and can be tailored for hardware and software. It is suitable for application-specific computer systems with strict requirements on function, reliability, cost, size and power consumption. It is generally composed of embedded microprocessors, peripheral hardware devices, embedded operating systems, and user applications, and is used to implement functions such as control, monitoring, or management of other devices.

The design technology of embedded systems mainly includes two major categories: hardware design technology and software design technology. Among them, the technology in the field of hardware design mainly includes chip-level design technology and circuit board-level design technology.

The core of chip-level design technology is compilation/synthesis, library/IP, and test/verification. Compilation/integration techniques enable designers to describe the required functionality in an abstract way and automatically analyze and insert implementation details. Library/IP technology uses pre-designed low-level implementations for advanced. Test/verification techniques ensure that each level is functionally correct and reduces the cost of repetitive design between stages.

Below we will introduce some basic development processes.

The first step: establishing a development environment

The operating system generally uses Redhat Linux, choose custom installation or full installation, download the corresponding GCC cross compiler through the network for installation (for example, arm-linux-gcc, arm-uclibc-gcc), or install related cross-compilation provided by the product manufacturer. Device

Step 2: Configure the development host

Configure MINICOM, the general parameters are baud rate 115200 Baud/s, data bit 8 bits, stop bit is 1,9, no parity, software hardware flow control is set to none. The same is true for the configuration of HyperTerminal under Windows. The MINICOM software is used as a monitor and keyboard input tool for debugging the information output of the embedded development board. The configuration of the network is mainly to configure the NFS network file system. The firewall needs to be shut down to simplify the setting process of the embedded network debugging environment.

The third step: establish a boot loader BOOTLOADER

Download some open source BOOTLOADER from the network, such as U. BOOT, BLOB, VIVI, LILO, ARM-BOOT, RED-BOOT, etc., transplant modification according to the specific chip. Some chips do not have a built-in boot loader, for example, Samsung's ARV17, ARM9 series chips, so you need to write the FLASH programming program on the development board, you can download the corresponding programming program on the Internet, there are also open source code under Linux J -FLASH program. If you can't write your own development board, you need to modify the source code according to your specific circuit. This is the first step in getting the system to work. If the user buys a manufacturer's emulator, it is easier to burn FLASH. Although it is impossible to understand the core technology, it can greatly improve the development speed for those who need to quickly develop their own applications.

Step 4: Download the Linux operating system that has been ported

Such as MCLiunx, ARM-Linux, PPC-Linux, etc., if there is a Linux operating system specifically for the CPU used, it is better, add a specific hardware driver after downloading, and then debug and modify, for the MMU The CPU can debug the driver in module mode, while for systems like MCLiunx, only the kernel can be compiled for debugging.

Step 5: Establish a root file system

Download the BUSYBOX software for feature reduction, generate a basic root file system, and then add other programs according to your application needs. Since the default startup script generally does not meet the needs of the application, it is necessary to modify the startup script in the root file system, which is located in the /etc directory, including: /etc/init.d/rc.S, / Etc/profile, /etc/.profile, etc., automatically mount the file system configuration file /etc/fstab, the specific conditions will vary from system to system. The root file system is generally set to read-only in the embedded system, and tools such as mkcramfs genromfs are required to generate the burned image file.

Step 6: Establish the FLASH disk partition of the application

Generally use JFFS2 or YAFFS file system, which needs to provide these file system drivers in the kernel, some systems use a linear FLASH (NOR type) 512KB ~ 32MB, and some systems use non-linear FLASH (NAND type) 8MB ~ 512MB, If two of them are used at the same time, you need to plan the partitioning scheme of FLASH according to the application.

Step 7: Develop the application

Can be placed in the root file system, can also be placed in the YAFFS, JFFS2 file system, and some applications do not use the root file system, directly design the application and the kernel, which is somewhat similar to the μC / OS-II way.

Step 8: Burn the kernel

Root file system and application, release product.

Recommended reading: embedded system development practice experience sharing

There are many techniques for developing highly reliable embedded systems, from well-developed development cycles to strict implementation and system checks. This article describes seven easy-to-use and long-lasting techniques that are useful for ensuring that the system runs more reliably and captures anomalous behavior.

Tip 1 - Fill the ROM with a known value

Software developers are often very optimistic people, just let their code run faithfully for a long time, and that's it. It seems quite rare for a microcontroller to jump out of the application space and execute it in an unintended code space. However, the chances of this happening are no less than the buffer overflow or the wrong pointer loses the reference. It does happen! The behavior of the system after this happens will be undefined, 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.

However, there are fairly comprehensive linker or IDE tricks that can be used to help identify such events and recover from them. The trick is to use the FILL command to fill a known bit pattern with unused ROM. To populate unused memory, there are many different possible combinations to use, but if you want to build a more reliable system, the most obvious option is to place the ISR fault handler at these locations. If something goes wrong with the system and the processor begins executing code outside of program space, it triggers the ISR and provides an opportunity to store the processor, registers, and system state before deciding to correct the action.

Tip 2 - Check the application's CRC

A big benefit for embedded engineers is that our IDE and toolchain can automatically generate an application or memory checksum (Checksum) to verify that 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 remains in memory, then verifying that the application is still intact at startup (or even for a long-running system) is an excellent way to ensure that unexpected things don't happen. The probability of a programmed application changing now is small, but considering the billions of microcontrollers delivered each year and potentially poor work environments, the chances of an application crash are not zero. More likely, a defect in the system can cause flash writes or flash erases in a sector, thereby damaging the integrity of the application.

Tip 3 - Perform a RAM check at startup

In order to build a more reliable and solid system, it is very important to ensure that the system hardware is working properly. After all, the hardware will fail. (Fortunately, the software never fails, the software only does what the code wants it to do, whether it is correct or wrong). Verifying that there is no problem inside or outside of the RAM at startup is a good way to ensure that the hardware can function as expected.

There are many different ways to perform a RAM check, but the usual method is to write a known pattern and wait for a short time before reading back. The result should be what you read is written. The truth is that in most cases the RAM check is passed, which is what we want. However, there is also a very small possibility that the inspection will not pass, which provides an excellent opportunity for the system to indicate hardware problems.

Tip 4 - Using a Stack Monitor

For many embedded developers, the stack seems to be a pretty mysterious force. When strange things started to happen, the engineers were finally stumped, and they started thinking, maybe something happened on the stack. The result is blindly adjusting the size and position of the stack, and so on. But the error is often unrelated to the stack, but how can it be so determined? After all, how many engineers actually did the worst-case stack size analysis?

The stack size is statically allocated at compile time, but the stack is used dynamically. As the code executes, the variables, returned addresses, and other information the application needs are continuously stored on the stack. This mechanism causes the stack to grow in its allocated memory. However, this growth sometimes exceeds the capacity limit determined at compile time, causing the stack to corrupt data in adjacent memory regions.

One way to absolutely ensure that the stack works properly is to implement the stack monitor as part of the system's "health" code (how many engineers will do this?). The stack monitor creates a buffer area between the stack and the "other" memory area and fills in the known bit pattern. The monitor then constantly monitors the pattern for any changes. If this bit pattern changes, it means that the stack is growing too much, and the system is about to be pushed to the 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 provided 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 developers. A quick search on the network reveals that many people recommend turning off the stack monitor in the real-time operating system to save 56 bytes of flash space. Wait, this is not worth the effort!

Tip 5 - Using MPU

In the past, it was difficult to find a Memory Protection Unit (MPU) in a small, inexpensive microcontroller, but this has begun to change. MPUs are now available from high-end to low-end microcontrollers, and these MPUs offer embedded software developers an opportunity to dramatically increase their firmware robustness.

The MPU has gradually been coupled to the operating system to create memory space where the processing is separate, or tasks can execute their code without worrying about being stomped on. If there really happen, uncontrolled process will be canceled, also performs other protective measures. Please pay attention to the microcontroller with this component, if any, please take advantage of this feature.

Tip 6 - Build a powerful watchdog system

One of the most popular watchdog implementations you'll often find is where the watchdog is enabled (this is a good start), but it can also be done with a periodic timer. The watchdog is cleared; the timer is enabled to be completely isolated from anything 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, ie when the work is suspended, the system will be forced to perform a hardware reset to recover. Using a timer independent of system activity keeps the watchdog clear, even if the system has failed.

Embedded developers need to think carefully and design how application tasks are integrated into the watchdog system. For example, there is a technique that allows each task that runs within a certain period of time to indicate that they can successfully complete their tasks. In this event, the watchdog is not cleared and forced to be reset. There are also some more advanced techniques, such as using 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 powerful watchdog system. Because there are too many technologies, it is difficult to fully cover them in these paragraphs, but for this topic, the author will publish relevant articles in the future.

Tip 7 - Avoid volatile memory allocation

Engineers who are not accustomed to working in resource-constrained environments may attempt to use the features of their programming language, which allows them to use volatile memory allocation. After all, this is a technique often used in calculator systems where memory is only allocated when necessary. For example, when developing in C, engineers may prefer to use malloc to allocate space on the heap. There is an operation to execute, once completed, you can use free to return the allocated memory for the heap to use.

In a resource-constrained system, this could be a disaster! One of the problems with using 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 handle it properly. And when they happen, what happens if the application asks for space but does not have the requested space available?

The problems caused by the use of volatile memory allocation are very complicated. It is a nightmare to properly handle these problems! An alternative approach is to simplify the allocation of memory directly in a static manner. For example, instead of simply creating a buffer that is 256 bytes long in the program, instead of requesting a memory buffer of this size via malloc. This allocated memory can be maintained throughout the life of the application without the concerns of heap or memory fragmentation issues.

The biggest feature of embedded software is control. The combination of soft and hard is more, the functional operation is more, the modules are called more than each other, the external working environment is complex and easily interfered or interfered with other devices, and the execution error The consequences are not only data errors but may lead to immeasurable disasters. Therefore, in summary, there are four aspects to be considered in the design of embedded software reliability:

1, software interface

2, hardware and software interface

3, software code

4, data, variables

For detailed reading, please click: Embedded Software Reliability Design Attention

These are just a few of the ways that developers can start building more reliable embedded systems. There are many other techniques, such as using good coding standards, bit flip monitoring, execution array and pointer boundary checking, and using assertions. All of these technologies allow designers to develop the secrets of more reliable embedded systems.

LCD Display Panel

Lcd Display Panel,Flat Panel Monitor,Lcd Touch Screen,Lcd Tv Panel

Huangshan Kaichi Technology Co.,Ltd , https://www.kaichitech.com