Today, a customer visited us. Their company used S3C2440 to create a product and encountered some issues:
1. Sometimes the program can be burned to NOR Flash using H-JTAG, and sometimes it cannot; when it fails to burn, H-JTAG shows an error message “Unable to load driver”.
2. When it is lucky enough to burn successfully, vivi can sometimes start, and sometimes it cannot.
3. After vivi starts, burning Nand Flash through USB always results in no response from the serial port.
Since the schematic of the main device is exactly the same as a FriendlyARM development board I have, and I am very familiar with the supervivi it uses, I initially thought that the hardware design was unstable, resulting in it sometimes running and sometimes not.
So, I modified a u-boot, reducing the CPU frequency from 400M to 200M, and the SDRAM frequency from 100M to 50M. After verifying it on the FriendlyARM development board, I burned it onto the customer’s board, but it still could not run.
All the above experiments were conducted using parallel JTAG for burning. At this point, using parallel JTAG was no longer feasible: the same board, the same program, can run on board A but sometimes not on board B. Anyone would think: it must be an unstable board!
But I did not want to stop there, so I used OpenJTAG to monitor the single board: connected OpenJTAG, and when the program was unresponsive, I executed the halt command to stop the CPU and check the registers. I found that the PC value was always 4, which indicates an “undefined instruction exception”. This means that the instructions fetched during CPU execution are incorrect. Were these instructions incorrect from the start, or did they get corrupted after running for a while? I needed to investigate further.
I then used OpenOCD’s “load_image u-boot.bin 0x33f80000” command to download u-boot.bin to the SDRAM at address 0x33f80000; then I used “verify_image u-boot.bin 0x33f80000” to compare the local u-boot.bin with the data in the single board’s SDRAM at 0x33f80000 and found the data to be inconsistent! Therefore, it can be concluded that: there is a problem with SDRAM operation.
Now, is the SDRAM issue caused by instability or a defect in the hardware itself (such as soldering)? Generally, we first determine whether it is a soldering issue because it is relatively easy to check. Debugging Steps:
I first used “mww 0x33f80000 0xaaaaaaaa” to write the data 0xaaaaaaaa to address 0x33f80000, and then used “mdw 0x33f80000” to read the data, finding that the obtained data was 0xaaaaaeaa; then I executed “mww 0x33f80000 0x55555555”, “mdw 0x33f80000”, and got the data 0x55555555.
Let’s pause for a moment. Why use the data 0xaaaaaaaa and 0x55555555 instead of others? This is because the binary of 0xa is 0b1010, and the binary of 0x5 is 0b0101. The numbers 0xaaaaaaaa and 0x55555555 can make the levels of the 32 data lines alternate, allowing us to observe whether adjacent data lines are shorted.
Now, analyzing the above results: writing 0xaaaaaaaa gives 0xaaaaaeaa, which means bit[10] should be 0 but is now 1; writing 0x55555555 gives 0x55555555, and bit[10] remains 1. From these two points, we can see that: the data line DATA[10] has a problem, but it is not shorted with the adjacent DATA[11] or DATA[9].
Based on this result, I conducted some additional experiments: “mww 0x33f80000 0”, “mdw 0x33f80000” gives the data 0x00000400, which also indicates that DATA[10] has a problem.
Now, let’s access the internal RAM to see if there is this phenomenon: “mww 0x40000000 0xaaaaaaaa”, “mdw 0x40000000”, and found that the obtained data is 0xaaaaaaaa.
So, the conclusion is: the external SDRAM’s DATA[10] is pulled high, which may be due to a short circuit during soldering. My experiments here concluded, and the customer took the board back to find the cause.
I cannot help but admire the power of OpenJTAG!
Note: The original post was published in October 2008
Additionally, our carefully upgraded official website www.100ask.org has quietly launched. After more than two months of work, we have optimized many elements. The new log is concise and clear, static pages have been changed to dynamic, and chat through the business bridge is more convenient. We especially spent a lot of effort on the teaching video section, which is rich in graphics and text, with course introductions, directory summaries, and preview links. Everything you need is there, and the server has been completely upgraded. To make it easier for everyone, we have abandoned the “login system”. It can be said to be quite considerate. We believe you will definitely like it. Go experience it now.