  |
Download Website
| ||
|
Shopping Cart
Download Website
|
| Home | Products | Teensy | Blog | Forum |
You are here:
8051 Tools
Development Board
Troubleshooting
Memory
|
|
Memory TestingThis page is primarily intended for troubleshooting boards built from the unassembled kit. All boards assembled at PJRC have their memory thoughly tested before they are shipped. This information may also be useful for anyone who built this design using wire wrap, point-to-point soldering, or breadboard construction; if a pre-programmed 87C52 chip was used, and the power, reset, crystal and serial port are functioning to allow access to the PAULMON2 memory editor.No technical support (other than this page) is available from PJRC for custom designed circuit boards or hand wired construction, even if it is closely based on this site's free schematics and other technical information. Assistance is available for problematic boards built from the unassembled kit sold by PJRC. There is no simple, easy test to determine which signals are not connected properly. The process involves using the memory editor to read, write and observe changes in the memory, looking for incorrect behavior. Once you see the memory respond erronously, with careful thought and analysis, you may be able to deduce what signals are likely to cause the behavior you observe in the memory editor. This page reverses this process. Known errors are created, and then the resulting memory behavior is explained. If you are lucky (but not lucky enough to get all signals connected properly on the first try), your board's behavior may closely match one of these scenarios. If not, this page may at least illustrate the basic principle and give you some initial experience to get you started on the path to understanding what is wrong. But first, before staring at screen after screen of memory editor display, there are some simple tests. Checking Each Memory TypeBefore digging into details with the memory editor, you can simply try to download files into each memory type. This should first be tried with all chips on the board, and alternately with only the target chip installed. This can give you a very quick check if a problem is with only one type of memory, or all types, and if there is some interaction (eg, the damaged RAM chip may interfere with using the flash chip which is not damaged).Download To RAMThis code downloads to the RAM chip at 0x2000.A correct download of this file should show this summary:
Download To Flash ROMThis code downloads to the Flash ROM chip at 0xF000.A correct download of this file should show this summary:
Download To 82C55/LEDs DirectlyThis file is a sequence of 1649 writes directly to the 82C55 chip which controls the 8 LEDs. The first write configures the chip, and the remaining 1648 writes disply a pattern where one LED is on at a time, starting with the one closest to the prototype area.A correct download of this file should show this summary, with 1 error:
The "unable to write" error is correct behavior. The 82C55 chip configuration register is write-only, so when PAULMON2 attempts to verify by reading back from that location, it does not get the same byte that was written. At 115200 baud, this download takes approximately 2 seconds. The LEDs display one on in an animated sequence from bottom to top. If you see this animation during the download, the 82c55 chip is receiving the data properly. Memory Editor TechniquesThe PAULMON2 memory editor can help you to "see" how your memory chips are responding. This approach can provide strong indication of what is wrong with your board. However, it requires understanding how the memory editor works (easy), and deducing what may be wrong with the hardware from observing the incorrect behavior (not as easy).The most important point about the memory editor is that it attempts to always show you the memory as it is read over the 8051's external bus. When you modify the conents of any location, the memory editor writes you new byte, then reads the memory and shows the value it read on the screen. The byte you typed it not shown... the actual value read back is what you see on the screen. However, when entering 8 bit hexidecimal values, your first keystroak is held in a register and the screen is updated with that value. When you make the second keystroak, your 8 bit number is written to memory. Then the memory is read from that same location and the value returned from the chip is shown on the screen. Do not confuse this first keystroak with working memory. It is being held in a register and the actual memory interaction takes place on the second keystroak. Likewise, only the byte you have just changed is refreshed on the screen. All others remain the same on the screen to avoid excessive (and slow) serial communication to update the full display. When testing memory, you will frequently type CTRL-L to cause the entire 256 byte display to refresh. Many types of problems with address lines are only observable by refreshing the full screen. Concentrate on the RAM first. The memory editor performs a sequence of write operations to write into the flash rom. Most wiring errors cause the flash chip to be utterly unwritable. If your board has a wiring or connectivity error, editing the RAM is your best chance to diagnose it. Case 1: Data Line Stuck At ZeroIn this first example, the D5 line is stuck at zero. This is a relatively simple problem to detect. If your board has a solder bridge like the one shown in Figure 1, you should have no problem discovering the nature of the error. Likewise, an open circuit (or poor solder connection) will often give similar behavior, stuck at zero or stuck at one.
When the memory editor is first entered, nothing initially appears to be wrong. Perhaps some people could notice that none of these 256 bytes has its D5 bit set? Because nearly all problems are observed by noticing the difference between an expected change in the display and the actual change that takes place, this page includes the initial display in each of these examples.
Usually, the first step is to press CTRL-E to enable editing, and then type several bytes to begin testing the memory. On the examples for this page, the pattern "0102040810204080" was typed. This enters 8 bytes where each has one bit set. Entering 00, FF, and 8 more with all but one bit set can also be helpful. In this case, the error is easy to see:
The byte at position 2005 is 00, when it should have been 20. Looking at these images does not have the visual impact that you get the instant your finger strikes that '0' key, and rather than "20" appearing, you see "00". In this case, it is very quick and easy to see the error and deduce that the D5 bit is not working properly. Note: all data line problems are also effectively address line problems because of the multiplexed bus design. In this section, we have ignored this effect for the sake of simplicity. See case #3. Case 2: Data Lines Shorted TogetherThis second example is very similar to the first one, but two data lines are shorted together.
Again, when viewing the initial screen, it's not immediately obvious that all these bytes have their D6 and D7 bits the same.
As before, once you start editing, the problem turns up quickly. Here, CTRL-E was pressed to allow editing, and "0102040810204080" was typed to enter 8 test bytes.
At location 2006, the incorrect "C0" is seen rather than "40", and the same occurs at 2007 rather than "80". In each of these cases, one line is driving low and the other high. By chance, both bits ended up being written as 1s to the memory, and then read back as 1s. The bits read back could be either both zero or both one. In this case, they were both one. If they had happened to be both zero, you might at first believe both D6 and D7 were stuck at zero. Using more tests with 00, FF, FE, FD, FB, F7, EF, DF, BF and 7F would quickly reveal that those two bits were not stuck at a particular value. Usually, the 8 simple cases with only 1 bit set are enough to quickly discover a problem, but if the error is not clear, trying 00, FF and the 8 bytes with only all but one bit set to 1 help provide more information. Note: all data line problems are also effectively address line problems because of the multiplexed bus design. In this section, we have ignored this effect for the sake of simplicity. See case #3. Case 3: Lower Address Line Stuck At ZeroNow, let's look at the more difficult case where an address line is not connected properly. This can also easily be detected using the memory editor, but the technique is different.
As usual, the initial memory editor screen does not make the problem obvious, though someone very observant might notice that groups of bytes are duplicated. Rarely is your time well spent staring at the initial display, because the problem will become very obvious as you interact with the memory.
As before, CTRL-E is pressed to enable editing, and the "0102040810204080" is typed to enter the basic 8 byte test pattern that worked so well in the previous two examples.
After entering the 8 bytes, the memory appears to be working perfectly. This is because each on-screen byte is the result of reading back only that byte after having written it. The other 255 bytes remain the same on-screen, because they are being held in the buffer of your PC's terminal emulator. Those other 255 bytes are old information stored on your PC, not the current state of the circuit board's observable memory. The next step is to press CTRL-L. For simplicity, this was not mentioned in the previous 2 examples. However, you should ALWAYS try pressing CTRL-L. Normally, nothing should change. When bytes change unexpectedly, you immediately know something is wrong, and that something is typically an error on the lower 8 address lines.
In this example, the bytes from 2008 to 200F unexpectedly change when CTRL-L is pressed. We know that this is because the A3 line is stuck at zero, as shown in figure 3. Deducing which address lines are bad can be tricky, especially when the error is a more difficult open-circuit that can fail as a 1 or 0 (and may change between attempts, or may be different depending on what data was previously transfered). Luckily, there are only 8 address lines to check when you see bytes mysteriously change after a CTRL-L. Warning: many multimeters output a large test current when used on their lower resistance measurement ranges, or their continuity (beeper) mode. If this test current flows through the static discharge protection diodes on a chip, that pin or the entire chip can be damaged. Check your multimeter's current level, and to be cautious, disable auto-ranging to force it to only output a safe current (less than 20 µA) for probing connectivity on the board while chips are installed in their sockets. Case 4: Upper Address Line Stuck At ZeroIn this example, A11 is shorted to ground. Sorry, no photo this time.Because the memory editor shows only 256 bytes at a time, it really isn't very useful for dianosing this type of problem. All the steps shown above will indicate that the memory is functioning properly. Fortunately, this type of problem is easy to see by just download blink_ram.hex. Everything appears normal at first:
However, if you press "M", it will appear there are two copies in memory:
The program can be run, and it prints correct output to the serial port. But the LEDs do not work, because attempts to write to the 82C55 chip at 0xF100 requires A11 to be one. Had the same error been on A10, the LEDs would work, but a second copy of the program would have appeared at 2400. A larger program would have overwritten itself at not been able to work properly. Connection problems on the upper address lines can be tricky, because many things will be able to work, or work partially with the good lower address lines and data bus. The memory editor only shows 256 bytes on the screen at a time, and everything will appear to work unless you very carefully compare different screens to each other (not easy). Duplicate copies of the program appearing in memory is the best indication of a problem on the upper address pins. Case 5: Address Line Shorted To Data LineSo far, the previous 4 cases covered data line problems, where the error is quickly recognizable, or address line problems, where any single byte works but other bytes mysteriously change. If you are very unluckly, you could have both problems at the same time!
In this case, a data line is shorted to an address line. As a result, we'll likely see both types of behavior. Unlike the previous cases, this initial memory editor screen "looks funny". There are several unlikely, visually recognizable patterns. But as before, guessing based on the initial display is difficult and observing behavior during editing is easy.
As usual, CTRL-E was pressed, and then "0102040810204080" was typed to do the simple 8 byte test.
The error at 2001 is immediately obvious, it's almost impossible not to see it when you are actually typing. At first, this appears to be the D1 line stuck at zero, as in case #1. CTRL-L should always be used as a quick check for the address lines. The following appears once CTRL-L is pressed.
It's immediately obvious something is wrong with one of the lower address lines, because bytes change unexpectedly upon pressing CTRL-L. But this display would lead you to believe that A1 is stuck, because the pattern repeats ever 2nd byte. In fact, the A1 signal is latched from the D1 signal by the 74HC373. So errors on D1 will cause A1 to be incorrect. Because of this dependance of the address bits on the data lines, the best troubleshooting strategy when mulitple problems are present is to fix the easier data bit problems first, then concentrate on the address bits once the data bits are working properly. Case 6: Wrong Chip SelectedMost of the signals are address and data lines, so an error at some random position on the board is most likely to impact address or data bits. However, all the memory devices require chip select and control signals, which can also have problems.This example shows an unlikely problem with chip selects, and also serves to illustrate some properties of the 82C55 peripheral chip.
In this sample, the error is a short between pins 4 and 5 of the 74HC138 chip, which forces the output of a 74AC20 gate to zero. The result is the flash rom never gets a chip select signal, and instead the 74HC138 chip always attempts to select a peripheral over the range 0x8000 to 0xFFFF, rather than 0xF800 to 0xFFFF. Before attempting the memory editor, you should notice the following when downloading the three sample files, leading you to believe the RAM and 82C55 (and all connections) are working properly, but you may have a defective flash rom chip. blink_ram.hex: downloads without errors and runs without problems. blink_82c55.hex: downloads correctly and LEDs respond properly. blink_flash.hex: does not download correctly, and strange problems result. When downloading to the flash, it will seem the flash is partially working but not storing data reliably. Each download attempt can produce slighly different results. If you try this with the flash chip removed, the same thing happens, which is very mysterious.
When you run the memory editor to begin investigating the problems with the flash rom, unlike usual, the initial screen gives the immediate impression that something is very wrong. It seems as if all the address bits except for A0 and A1 are not working.
If you try editing this, you will find that locations F000, F001 and F002 appear to be working memory, but F003 does not. If you press CTRL-L before editing F003, your impression that only A0 and A1 is reinforced because the whole screen changes. If you edit F003 (which does not read back correctly) and then press CTRL-L, all the bytes change to zero. This is the correct behavior of the 82C55 peripheral chip. The "+3" location is the write-only configuration register. When it is written, the 82C55 chip clears the other three registers to zero. The other 3 bytes are read/write registers that control ports A, B and C. The important point is to recognize that memory mapped peripheral chips like the 82C55 have very unusual behavior when you are expecting ordinary memory. These chips usually only have a small group of registers (4 in the 82C55), so they appear repeated over and over again in memory. This is not bad address bits. Recognizing this behavior as the 82C55 chip is the critical step that will lead you to troubleshoot the address decoding logic. It appears at first that the flash chip is defective, but in fact it is most likely perfectly fine, but not actually being used because of an error in the chip selection based on the address bits. Case 7: No Chip SelectedOne final case to be aware of is the circumstance where no chip is responding. This is easy to recognize, because each byte reads the same as its lower 8 address bits, and all attempts to write have no effect.When you see this in the memory editor, and all attempts to edit have no effect, there is probably no chip being selected.
You might expect to see all bytes with the same value, but that is not the way the hardware works. Because of the multiplexing of the lower 8 address bits with the data lines, the 8051 drives the data bus with the lower half of the address. Then when it reads the bus less than one microsecond later, the lines are "floating", with their capacitance charged (or discharged) to the same voltage that was used during the address output to the 74HC373. The result is the display you see here. Recognizing this condition can help you quickly know what is (or isn't) wrong when you see it. No (or very few) Easy AnswersTroubleshooting memory problems is frustrating. There are no simple, easy tests that quickly diagnose all types of problems.By downloading to each type of memory, both with and without the other memory chips installed, you can get some initial impressions about whether the chips are working. But as the chip select example (case 6) shows, even that simple technique can be deceptive. Most memory errors are easy to spot in the memory editor once you start writing to the memory. Pressing CTRL-L to refresh the screen is a critically important step, because address line problems manifest themselves as other related locations unexpectedly changing. Data line problems cause address problems due to the mulitplexed bus, so simpler data bit problems should be solved first before address lines. Reversing the process shown here, where you can see the incorrect behavior and need to deduce the hardware cause requires good knowledge of the schematic, strong deductive reasoning, and sometimes dumb luck. Often, after staring at the incorrect on-screen performance, taking a break or even "sleeping on it" can help give you a fresh perspective to recognize what it really means. Hopefully this page has at least illustrated the process (if in reverse) and shown some of the more common problems. Technical SupportPJRC does not provide technical support for boards built using components purchased from other companies. The text of this page is the only assistance available if your board is hand wired on a breadboard, or using point to point solder or wire-wrap construction.However, if you built a board from the unassembled kit and it has memory access problems, perhaps we can help. Usually there is a fee for repair to boards build from kits, but it is much less expensive than buying a whole new board. All assembled and tested boards sold by PJRC should not have memory problems. Assembled boards (with the green dot on the serial port) are fully tested and the circuitry is known to be good before they are shipped. Damaged boards can be repaired simply by replacing the chips. Difficult memory editor techniques are rarely needed for the assembled boards. |
Software
