Two problems encountered during the debugging of the S3C2440 Development Board

I want to write a special article to illustrate the problems encountered in the debugging process of our development board. Now I have time to summarize them. There are two main problems.

1. Unable to halt ARM core

After the development board is ready, we can't wait to write supervivi in nor flash to see if our board works properly. There are two methods to burn or flash. One is through H-JTAG, and the other is through J-link. We first use the H-JTAG. After the board is powered on, it can detect the arm9-chip. However, when programming the nor flash, problems may occur, the software prompts "unable to halt ARM core". After J-link is used, the problem persists. At that time, we were a tangle!

I searched for these keywords. The online statement was that the reset was not successful, or the nwait was not pulled up. As a result, the CPU kernel was not successfully stopped, so JTAG could not communicate with the CPU normally, therefore, you cannot burn programs to flash. However, our Board does not have this problem. In addition, we carefully checked the connection between the CPU and flash pins, checked the Connection Methods of the OM [] pins, And the CPU power supply, no problems found. At last, the Senior brother found a resistor on the purchased core board, carefully checked the schematic diagram, and found that the resistor was connected to the nbatt_flt pin of the CPU and pulled on the 3.3v. On our board, the pin is suspended, and we read the S3C2440 chip manual, which says that the pin must be pulled up (3.3 V) when it is not in use ). Fortunately, at the time of drawing board, this pin was drawn through a hole, so we soldered a pull-up resistor. Power on again, OK! Everything goes smoothly until the following problem occurs ......

2. Intermittent network connection

First of all, the NIC chip I use is dm9000ep. After writing bootloader, Linux kernel, and file system to NAND Flash, follow the micro2440 User Manual to test its Telnet function. After connecting the host to the Development Board with a crossover network cable, the local connection in the lower right of the host shows the connection for a while, and the connection is closed for a while. After the host and the Development Board are set to the same network segment, the two sides Ping each other and cannot Ping each other. The software is certainly okay, because it is completely normal for us to experiment on the friendly arm platform. Next, I looked at the hardware again. At the beginning, I still checked the circuit diagram to see if a pin was not connected like the core board, but I did not find any problems after the work was completed. Then, I decided whether my cabling was not standard? But the general circuit is not so delicate. Under Bai bored Nai, I removed and installed NIC-related devices on the friendly arm micro2440 Board to see if I could simulate this problem. In the end, I couldn't help it. I tried to unload the dm9000ep chip on the good board and weld it to our board. I didn't expect it to succeed! OMG seems to be a chip batch problem.

These two problems have plagued us for more than two weeks. However, after the problem is solved, we feel refreshed. Here, I would like to share some of my experiences with embedded learning. On this open platform, we are not fighting alone!