**How to Avoid Hidden but Common Software Defects in the PCB Design Process, and Techniques to Help Engineers Detect Hidden Errors in PCB Copy Board Software**
Most software development projects rely on a combination of code inspection, structural testing, and functional testing to identify software defects. While these traditional techniques are essential and can catch many issues, they are not sufficient to detect several common errors in today’s complex systems.
**Structural Testing (White Box Testing)**
Structural testing, also known as white box testing, is effective in uncovering logic errors, control flow issues, calculation mistakes, and data inconsistencies in the code. This type of testing requires insight into the internal workings of the software (hence the term “white box” or “glass box”), providing a detailed view of the software structure. It involves checking every conditional expression, mathematical operation, input, and output. Due to the large number of details that need to be tested, structural testing typically focuses on one software unit at a time, such as a function or class.
**Code Reviews**
Code reviews share similar complex techniques as structural testing, helping to identify implementation flaws and potential issues. Like white box testing, reviews are generally conducted on each individual unit of the software. An effective code review process involves centralized, thorough inspections to catch any errors or inefficiencies in the code.
**Functional Testing (Black Box Testing)**
In contrast to code reviews and white box testing, functional testing, or black box testing, assumes no knowledge of the software’s internal implementation. It focuses on testing the software’s outputs based on controlled inputs. Test procedures are written by testers or developers, specifying the expected program outputs for a given set of inputs. After executing the tests, the tester compares the actual output with the expected result to identify discrepancies. Black box testing is particularly effective in uncovering unmet requirements, interface issues, performance problems, and errors in frequently used functions of the program.
Although combining these techniques can identify most of the errors hidden within a software program, they also have certain limitations. Code review and white-box testing focus on only small portions of the code at a time, leaving other parts of the system unexamined. On the other hand, black-box testing treats the system as a whole, disregarding the details of its implementation. Some critical issues can only be uncovered by examining how components interact within the entire system, and traditional methods may not reliably identify such problems. To pinpoint the root cause of specific issues, the system must be analyzed as a whole. Since thoroughly analyzing every detail of the program and its interactions with all other parts is typically not feasible, the analysis should focus on the areas of the program known to be problematic.
This article will explore three potential problem areas:
* Stack Overflow
* Race Conditions
* Deadlock
The second part of this article, available online, will cover the following issues:
* Timing Issues
* Reentrant Conditions
All of these problems are quite common in systems that utilize multi-tasking real-time design techniques.
### Stack Overflow
The processor uses the stack to store temporary variables, pass parameters to functions, save the thread’s state, and more. In systems that do not use virtual memory (i.e., those that cannot swap memory pages to disk to free up space), the stack size is fixed at the time of manufacture. If, for any reason, the stack exceeds the range allocated by the programmer, the program’s behavior becomes unpredictable. This instability can lead to severe system failures. Therefore, it is crucial to ensure that the system can allocate sufficient stack space for the worst-case scenario.
The only way to guarantee that a stack overflow never occurs is to analyze the code, determine the maximum stack usage under all possible conditions, and verify that the allocated stack size is adequate. Testing is unlikely to reproduce the exact combination of inputs that would trigger a stack overflow in the worst-case scenario.
Stack depth analysis is conceptually straightforward:
1. Construct a call tree for each independent thread.
2. Determine the stack usage of each function in the call tree.
3. Examine each call tree to identify the call path from the root to the outer “leaf” that requires the most stack space.
4. Add up the maximum stack usage for each independent thread’s call tree.
5. Determine the maximum stack usage for each interrupt service routine (ISR) at each interrupt priority level, and calculate the total. However, if the ISR does not have its own stack and instead uses the stack of the interrupted thread, add the maximum stack usage of the ISR to the thread’s stack.
6. For each priority in PCB layout and design, include the stack space required to save the processor state during an interrupt.
7. If using an RTOS, account for the maximum stack space required for the RTOS’s internal operations (which differs from the stack usage for system calls triggered by application code, as covered in step 2).
Additionally, there are two key considerations. First, a call tree constructed from high-level language source code may be incomplete. Most compilers optimize common operations, such as large integer multiplication/division or floating-point operations, using runtime libraries. These calls are only visible in the assembly language generated by the compiler. Runtime library functions can consume significant stack space, and they must be included in the analysis. If using C++, all of the following function types (methods) must also be incorporated into the call tree: constructors, destructors, overloaded operators, copy constructors, and conversion functions. Moreover, all function pointers must be parsed, and the functions they reference should also be analyzed for stack usage.
If your have any questions about PCB ,please contact me info@wellcircuits.com
