The engineer explains the search of software defects in PCB design

The engineer explains the search of software defects in PCB design

This article will introduce how to avoid those hidden but common errors, and introduce several techniques to help engineers find hidden errors in PCB copy software. Most software development projects rely on the combination of code inspection, structural testing and functional testing to identify software defects. Although these traditional technologies are very important and can find most software problems, they cannot detect many common errors in today's complex systems.

Structural testing or white box testing can effectively find logic, control flow, calculation and data errors in code. This test requires a clear view of the internal work of the software (thus called "white box" or "glass box"), so as to understand the details of the software structure. It checks each conditional expression, mathematical operation, input, and output. As there are many details to be tested, structural testing checks one software unit at a time, usually a function or class.

Code reviews also use techniques as complex as finding implementation defects and potential problems. As with white box testing, reviews are usually conducted for each unit of software, because an effective review process requires a centralized and detailed review.

Unlike reviews and white box testing, functional testing or black box testing assumes no knowledge of the software implementation and tests outputs driven by controlled inputs. Functional testing consists of testing procedures written by testers or developers, which specify the expected program output corresponding to a specific set of program inputs. After the test runs, the tester compares the actual output with the expected output to find the problem. Black box testing can effectively find out the unmet requirements, interface problems, performance problems and errors in the most commonly used functions of the program.

Although these techniques can be combined to find most errors hidden in a particular software program, they also have limitations. Code review and white box testing only focus on a small part of the code at a time, ignoring other parts of the system. Black box testing usually treats the system as a whole, ignoring the details of implementation. Some important problems can only be found by focusing on their interactions in the whole system; Traditional methods cannot reliably identify these problems. The software system must be examined as a whole to find specific causes of specific problems. Since it is usually impossible to thoroughly analyze every detail of the program and its interaction with all other parts of the code, the analysis should focus on specific aspects of the program that are already known to cause problems.

This article will explore three potential problem areas:

*Stack overflow

*Competitive conditions

*Deadlock

Readers can read the second part of this article online, which will explore the following issues:

*Timing problem

*Reentrant condition

All of the above problems are quite common in systems using multitask real-time design technology.

stack overflow

The processor uses the stack to store temporary variables, pass parameters to the called function, save the thread "state", and so on. If the system does not use virtual memory (in other words, it cannot transfer memory pages to disk to free memory space for other purposes), the stack will be fixed to the size of the product when it leaves the factory. If for some reason the stack exceeds the number allocated by the programmer, the program will become uncertain. This instability may lead to serious system failure. Therefore, it is important to ensure that the system can allocate enough stacks in the worst case.

The only way to ensure that stack overflow never occurs is to analyze the code, determine the maximum stack usage of the program under various possible conditions, and then check whether enough stacks are allocated. It is unlikely that the test will trigger a specific combination of instantaneous inputs, resulting in the worst case of the system.

The concept of stack depth analysis is simple:

1. Create a call tree for each independent thread.

2. Determine the stack usage of each function in the call tree.

3. Check each call tree to determine which call path from the tree root to the external "leaf" needs the most stack.

4. Add the maximum stack usage of each independent thread call tree.

5. Determine the maximum stack usage of each interrupt service routine (ISR) within each interrupt priority and calculate its sum. However, if the ISR itself does not have a stack and uses the interrupted thread's stack, the maximum number of stacks used by the ISR should be added to each thread's stack.

6. For each priority, add the number of stacks used to save the processor state when an interrupt occurs.

7. If RTOS is used, add the maximum number of stacks required for RTOS's own internal use (different from the system calls caused by application code, which have been included in step 2).

In addition, there are two important matters to consider. First, the call tree built only from high-level language source code may not be perfect. Most compilers use the runtime library to optimize common computing tasks, such as multiplication and division of large integers, floating point operations, etc. These calls are only visible in the assembly language generated by the compiler. The runtime library functions themselves may use a large amount of stack space, which must be included in the analysis. If the C++language is used, all the following types of functions (methods) must also be included in the call tree: constructors, destructors, overloaded operators, copy constructors, and conversion functions. All function pointers must also be parsed, and the functions they call must be included in the analysis. The introduction engineer of PCB assembly, PCB design and PCB processing manufacturers explained the search for software defects in PCB design.