The article introduces that the embedded system development process is actually a process of debugging and diagnosis, and the debugging diagnosis will always be accompanied by the lifetime of a product. Even the most mature products occasionally have such problems or problems, which requires developers. Go to diagnosis and troubleshooting.
The debugging of the embedded system includes hardware debugging, software debugging and comprehensive debugging. Hardware debugging generally refers to the check before and after power-on when the system is just developed, including:
1) Check whether the power supply and ground are short-circuited before power-on, and visually check whether there is any welding or missing welding;
2) After power-on, check whether the frequency and waveform and amplitude of the clock line are normal, whether the power supply voltage is stable and normal, whether the temperature of each chip is normal, and whether the indicators are normal.
Software debugging generally refers to ensuring that the timing of the execution of the program is correct under the condition that the hardware is all normal, whether the logic and the result are consistent with the design requirements, and whether the function and performance requirements can be met. There are many ways to debug software, including:
1) Track and debug with the indicator light;
2) Print and debug with serial port;
3) Assembly code level debugging with a simple debugger;
4) Source code level debugging with a relatively high-end debugger;
5) Hardware simulation with the simulator.
The above simple hardware debugging or software debugging is relatively simple, and the difficulty is comprehensive debugging. Below I will first mention some difficult problems that I have encountered in my work, and then summarize some general debugging methods and precautions.
Example 1: The debugging of our self-designed PPC860 (Motorola) network engine platform is nearing completion. All the 4 boards produced in the same batch have passed all software tests, so we have welded the second batch, but in the second batch of boards. The FEC with one board is not working properly. Several software and hardware engineers used various methods to re-read the chip manual. I still didn't find out the reason, so I sent the board back to the factory to re-weld the BGA, but I came back. The problem still exists. There is no way to finally treat the board as a sample and solder the chips on the board. According to common sense, this approach is very logical, because the components are the same, the board is also a batch, it may be that somewhere in this board is not well welded, but it is not easy to check, repeated re-welding may Will solder the motherboard. Later, some people from the PPC860 chip with a magnifying glass have to open their eyes to see the characters (it is said that China's first generation of domestic high-end processor chip "Chill Heart" is a "scientist" will "Motor" on the same type of chip on these letters After the "Cold Heart One" is changed, it is found that the CPU version number of this board is "D4", and the CPU version number of other boards is "D3". A comparison between the versions shows that the PPC860 errata manual was found on the Internet. It was found that in the PPC860TZP50D4 version, a bit called bit FEC_PIN_MUX (bit2) was added to the ECNTRL register to control the multiplexing function of each FEC pin. If FEC is to be used, This bit must be set to 1, so add the ECNTRL |= 0x00000004 statement line to the relevant program in the FEC.
Example 2: When I debug the amateur MC68VZ328 board, there is no problem with the board hardware check. The Code warrior uses the serial port to burn the compiled uClinux program through the serial port. Everything is normal, but the power is turned on again and the serial port has no data. I checked with a multimeter (there was no "advanced equipment" such as an oscilloscope at the time) and I didn't find out the result. Then I went to work every day and put the board in the bag. If I had nothing, I took it out and looked at it. I couldn’t help but see the fire, but One day, I found a place marked with a resistance symbol but soldered the capacitor. When I got home, I put the resistor on and then power it on. The serial port prints out the boot information of uClinux. Oh, that tastes sweeter than drinking honey. Of course, It was also because there was not much experience. If this problem is put forward, it is estimated that it will be solved within one day. In addition, when debugging the self-made S3C4510 development board for the first time, it is impossible to output characters from the serial port. It took a long time to find that the polarity of the capacitor on the sixth pin of the serial level conversion chip max3232cse was reversed.
Example 3: When debugging the SB1250 embedded server motherboard, due to the use of the DDR1 memory module, the decoupling capacitor resistance of the serial and parallel connection of the data line and the clock line is quite large, and almost no one of the first batch of soldered boards can enter smoothly. CFE (BIOS) menu interface, check the clock waveform and power supply and the borrowed DEMO board are very good, I put all the decoupling resistors and capacitors around the DDR DIM slot on the motherboard all over the tin with a soldering iron, oh, also This is a very useful method, and it is also very useful to use this trick when debugging PCI and HT bus later. It may be because the SB1250 system is a high-frequency circuit. The welding requirements are relatively high, and there is a slight leak or weak soldering. ,I think so.
From the above examples, we can summarize the following debugging methods and precautions:
1) Deepen understanding: deepen understanding, including deepening understanding of hardware and software, deepen understanding of hardware is mainly to read the relevant chip data manual in detail, and deepen the understanding of software because now the development of embedded systems is not all programs You need to write your own, many of them are already done, directly obtained from the Internet or purchased, but the software is not necessarily completely targeted to our own target board, so often find some problems in the use process, especially the underlying software. And in the event of a problem, the developer must first understand the code in question. It is only based on a deep understanding of the relevant hardware and software that it is possible to make more realistic judgments, and it is possible to solve the problem better.
2) Comparison method: There are many methods of comparison, such as comparing the same software on two similar but different hardware platforms; comparing two different versions of software on the same hardware platform; Compare the same software on the same batch but on two different hardware platforms. For some problems that are not very concealed, the comparison method usually gives good results.
3) Decomposition method: When encountering a problem that is complicated to analyze and may have many factors, you can divide the problem into several small problems to test the diagnosis. For example, write several separate small test programs to check various possible factors. Test, and then make scientific judgment based on these test results.
4) Software and hardware combination method: This method requires some inspiration and understanding. For example, in the above example 5, during the test, you can temporarily change the state of the hardware without breaking the hardware (such as short-circuiting the data line and the clock line in this example) to see if the problem will change. Yes, so many similar tests are done to find out the changing laws and key factors, and then analyze and solve them. In the underlying software development, special attention should be paid to the software programming of the time-critical hardware modules. Once the timing of the program is out of order, and this part of the software has been integrated with other system software, then the software allows others to check It is difficult to find out the problem.
5) Diagnosis and troubleshooting should be based on a large number of experiments. It is necessary to be more hands-on, not to know delusions, not to practice, but also to be "being good at thinking and analyzing." Embedded system development is a very practical science. It is necessary to summarize the objective laws of things in practice so as to better understand and use them so that they can work better according to our intentions.
6) Embedded system development and debugging requires developers to have a rigorous and meticulous work attitude, and never let go of any clues found during the debugging process, because it is likely to be the key to open the Pandora's box.
7) To have a work style of seeking truth from facts, we must have the spirit and courage to dare to doubt everything. We should respect the authority and the scientific and technological achievements of our predecessors, but when there is a contradiction, we should believe in the experimental results so that science can progress.
8) Be brave enough to challenge yourself, abandon habitual thinking and prejudice, broaden your thinking, and analyze problems from multiple angles.
9) Embedded system development, especially the underlying software and operating system kernel development, because it needs to deal with software and hardware at the same time, it is a very difficult job, very challenging. Even if we do very well in all aspects, consider it very carefully, the target system may still make some small jokes with us, we often encounter a very small problem that plagues us for days or even weeks, this During the period, we may not think about tea and night, so the underlying software developers of embedded systems should not only have a peace of mind, but also have certain patience and perseverance, but also have the courage and confidence to overcome all difficulties! As long as we do Good enough, then the process of solving a specific problem has some contingency, but we will rule out all obstacles!
Therefore, the embedded system debugging process is a process of deeper understanding of our target system and the characteristics of each unit module in the system. It is a process of exercising our logical thinking and analytical reasoning ability, which is a way of developing ideas and habits. The process of thinking and authority challenge is a process of rigorous and meticulous work attitude and practical work style. It is a process of exercising our endurance and perseverance, and ultimately a process of learning and progress!
The improvement of debugging and diagnostic capabilities of embedded systems is a long-term practice, accumulation and improvement process!
57 Series Centronic Connectors
Current Rating:5A
Dielectric Withstanding Voltage:1000V for one minute
Insulation Resistance:1000MΩ Min.(at 500V DC)
Contact Resistance:35mΩ Max.
Temperature:-55°C to +105°C
57 Series Centronic Connectors
ShenZhen Antenk Electronics Co,Ltd , https://www.antenkelec.com