|Shopping Cart Download Website|
|You are here: MP3 Player Detailed Info Troubleshooting|
Troubleshooting the MP3 Player BoardHopefully everything will go smoothly with setting up the MP3 player board, but since the board is supplied without a power source, SIMM or hard drive, and in some cases the boards are built from a kit, there are a number of things that can go wrong.
You may need the following items for troubleshooting.
Before you send email or post in the yahoo group for help, please take a moment to identify which board revision you have (printed on the board between the large Xilinx chip and the SIMM socket), and be sure to mention if your board was assembled/tested by PJRC (green dot on serial port) or built from an unassembled kit. If you have tried any of the tests on this page, please mention the results. If can see the messages from the serial port, always attach a text capture of the serial port messages. These messages contain a lot of very useful information that can really help to diagnose problems.
Nothing Happens When I Turn On The PowerPerhaps the most frustrating problem is when the player appears to be "dead". The firmware will always transmit messages to the serial port, regardless of what is connected to the board. The first step is to connect the serial port to a PC and attempt to view the messages the MP3 player sends. Disconnect everything from the board, except for power and the serial cable, so you can concentrate on receiving the serial port messages without interferance from possible sources of trouble.
When there is no response, the problem is generally one of these four scenarios (listed in order of likelyhood):
Power Supply Not Coming On (Inadaquete Power)The vast majority of trouble with the mp3 player is related to an inadaquete source for power. There are three requirements for the input source:
DC Voltage may be applied to either power input on the board. The 12 volt input is intended to allow the player to run from a car's electrical system or a standard 12 volt DC power source. The lower voltage input is primarily intended for battery, but lower voltage power supplies may also be used. AC voltage (as a few "wall wart" plugs output) will not work, so check the specs to make sure your power is DC voltage. This table summarizes the voltage ranges:
Current Capacity required on the 12 volt input is generally 1000 mA for use with a laptop drive, or 300 mA without a laptop drive (an external 3.5 inch drive will require external power, as specified on the drive). More current, up to 2 amps (or 3 amps on Rev A/B) can be required on the battery input during the brief time while a laptop drive's motor is accelerating. Because of this large short-term current requirement, Alkaline batteries should NOT be used. NiCD and NiMH batteries, as well as sizable lead acid (including "gel cell") batteries are able to provide these startup currents.
Power sources with low voltage or insufficient current capability are usually noticed when using a laptop drive. Typically, the laptop drive will make a click as its motor attempts to spin, and then the player will reboot, repeating the click/reboot over and over. In some extreem cases, the player's power supply will experience trouble. On Rev A and Rev B boards, the NDS6060L transistor (the large one closer to the serial port) will become hot, but rarely does this damage it. Rev C includes a shutdown circuit that will shut off the player until all power has been completely disconnected for several seconds!
Inrush Handling is primarily a concern with Rev A and Rev B boards, where the board draws a large current for a very brief time when power is first connected. Rev C includes inrush limiting circuitry and lower value capacitors, yet a 470µF capacitor must still be charged when power is applied. With most "normal" power sources, this is not an issue. Lab bench power supplies with fast-acting current limiting are usually sensitive to inrush (they are meant to power circuits directly, not another power supply). Some small/lightweight power supplies for power-hungry laptop computers, ethernet switches and similar equipment are actually switching power supplies with fast response current limiting. Often these will work if they are connected to the mp3 player when they receive power, but not if they are already "live" an then attached to the player. Inrush compatibility problems are easy to spot (with a voltmeter) because the output of your power source will drop to a very low voltage instead of its rated/regulated output voltage. Lab benchtop supplies typically have an LED to indicate current limiting mode.
Serial Port Does Not CommunicateTODO: this text was from a message I wrote in the yahoo group... much editing and rearraning is need to fit this web page.
2: The first step is to do a "loopback test", which is a simple test to check if your serial port, cable, and terminal emulation software are working. This test is done without the mp3 player board. Here's a description of the test: http://www.pjrc.com/tech/8051/board4/troubleshooting.html Problems on the PC are common, such as selecting the wrong com port. Hyperterminal can also show the "scroll buffer" and not "live" data if you've clicked on the scroll bars inadvertantly, and of course it can be ignoring all incoming data if flow control is selected, so it's important to do this simple loopback test to make sure that incoming data is really going to display on your screen. The loopback test does not check the baud rate, so make sure it's set to 19200 baud, 8 bits, no parity, 1 stop bit (with a wrong baud rate, you'd usually get garbage instead of nothing)
3: The MP3 player will start up and send messages to the serial port without the hard drive and simm (the messages will tell you they are missing). It's best to completely remove the simm and hard drive until you've managed to get some response from the board on its serial port.
TODO: voltage measurements (DC, AC rms, AC on cheap meter) when the board is printing dots waiting for hard drive... need to get both rev C and rev A/B, for a total of 6 voltages.
4: The first major test is to determine if the board is powering up properly, as nothing else will work without proper power. If you have the LCD connected, a sign that there is power is if the pixels all go from off or full on as you slide the contrast adjustment (on the top) from the left to the right side. Without the LCD, you really need a voltmeter. On rev C boards, there are a pair of square pads on the top edge near the upper right corner, and they are labeled "5V - +". Probe these with the meter and you should see +5 volts. If not, something is wrong with the power.
5: Most of the circuitry runs on +3.3 volts, and you can probe that on pins 8 and 16 (corner pins) of the 74HC165 chip. When the +5 volts is working, +3.3 will almost certainly also be good unless the board is damaged. However, the most common damage is to blow the FPGA chip, and it usually blows as a short that holes the +3.3 volt power at a low (unworkable) voltage, such as 0.6 volts. If you're comfortable probing the corner pins of the 74HC165 chip, you can check the +3.3 volts and make sure it's ok.
6: Another voltmeter-based test is to measure the voltages on pins 2 and 3 of the serial port, while the PC is connected. In each test, the meter's ground should touch the board's ground (pin 5 on the serial port, or the metal frame on either of the RCA line-level audio jacks). Pin 2 is the signal sending data from the mp3 player to the PC, and it should be approx -6 to -10 volts. Pin 3 is data from the PC to the mp3 player, and it should be at a similar voltage (usually about -11 for a non-laptop PC). If either of these reads close to zero volts, it's a sure sign something is mis-wired about the serial port (no voltage on pin 3 would indicate a bad or null-modem cable).
7: At this point, we're getting into the circuitry on the board. The MAX810 chip is responsible for reseting the CPU and getting the board to boot. It is supposed to output +3.3 volts for about 0.2 seconds after you apply power, to keep the CPU in reset, and then it goes to nearly zero volts to allow the 87C52 to execute code (and one of the first things it does is transmit the welcome message at 19200 baud). On Rev C, the MAX810 output is the pin on the right closest to the SIMM. This is a tiny pin, so be careful if you try to probe it. On some damaged boards, in the less common case where the FPGA was damanged, but not enough to turn it into a complete 3.3-killing short, the FPGA will drag the +3.3 volts down briefly when the CPU boots. This causes the MAX810 to reset the CPU (since it's job is to prevent the CPU from running until the voltage is high enough), and this cycle repeats resulting in a measurement on the MAX810 output that is somewhere between 0.3 to 2.7 volts, and appear to be "unstable" (changes somewhat randomly, depending on the update speed of your multimeter). If the MAX810 measures a steady signal, such as 2.9 volts, then it is not allowing the CPU to run due to low voltage. It is supposed to be high for only a fraction of a second when the board is powered up, and then it should stay low (very close to zero volts).
Here are some simple voltmeter tests to see if the board's serial port is working and able to transmit data. First, make sure that NOTHING extra is connected to the mp3 player. Use only the serial port and power. Do not connect the LCD, simm hard drive and audio.
Laptop Drive Makes Click-Click-Click SoundPower Inadaquete
Shuts Off When Starting Hard Drive, Won't RebootPower Inadaquete
Hard Drive Not Detected, Prints Dots Endlessly.........................Cable / power connected correctly?
Master / slave setting? (recent firmware auto-detects this)
Reads MBR IncorrectlyIncompatible drive? This isn't very common. Need to get one of these drives for testing.
I think this problem was solved with the CHS init for old/buggy drives.
Invalid Partition TypeMust be FAT32, Type 0B or 0C (0C added in rev 0.1.1)
Extended partition tpyes (05) not supported
0.6.10 adds printing of names for several unsupported types
TODO: add long list of partition types (linux fdisk, other sources???)
TODO: what does the user see with firmware revs that require some files in the root directory, but none are present?
Plays Chunks of Songs Mixed Together, Sometimes StopsMust defragment the drive for 0.1.x and 0.5.x. Using Microsoft defrag program.
Might be firmware bug (text capture with debug message req'd to investigate)
SIMM Detected Too SmallSIMM doesn't use Micron datasheet specs.
RAS0 only mode
Internal matrix has one dimension larger than 11 bit address
Generally Works, But Random Crashes, Garbage, Audio GlitchesSIMM compatibility, FPGA timings
IDE cable length
Possible noise/interference from RF, switching power supplies with unusal grounding
I am collecting problematic simms and often times I'll swap these for known-good ones.
Only Plays Part Of Each Song0.6.x firmware only buffers as much as will fit into the SIMM
0.5.1 and 0.1.3 play any length, but drive stays on
0.7.x will make better use of the memory
Audio Glitch When Next/Prev Button PressedBug #32 (yes, it will get fixed eventually... the silent clip idea was supposed to fix it, but didn't solve it 100%)
Strange Noises With Hard Drive Or Serial Port ActivityGround loop issues.
Suggesting from John Bohman: Radio Shack has a group loop isolator transformer for $15, P/N 270-054. It comes with a converter from RCA to 1/8" stereo jack as well.
Giant Hex Dump, Message About Bad SIMMDoes this ever happen anymore? Usually it's a firmware bug.
A serious error was detected, which probably was the result of memory somehow getting corrupted. It could be that your SIMM is bad. It's also possible that there's a problem with the address connections to the SIMM on your circuit board, or there could be a bug in this firmware.
Damanged Board, No Serial Communication
Damanged Board, Power Supply
Damanged Board, Burned Ground Trace
Built From An Unassembled Kit, Nothing WorksWhen the player is hand soldered from the unassembled kit, almost anything could be wrong. This section will try to give some basic things to check to help isolate the problem.
First, check the power. The player runs internally on +5 volts and +3.3 volts. On a Rev C board, the +5 volt power is easily tested on a pair of pads on the top edge of the board. A LP2950-3.3 chip creates the +3.3 volts, which can be measured on pins 8 and 16 of the 74HC165 chip. On Rev A boards, both +5 and +3.3 volts are produced from the switching power supply. The rest of this section will focus on Rev C.
If the +5 volt power is bad, then something is likely wrong with the switching power supply section of the board. Check the 1N5817 diode to the right side of the transformer. This diode will prevent current from flowing back into the transformer if you power the board from an external +5 volt regulated supply. It is recommended to use an external +5 volt supply to power the board for testing, and return to the power supply after the rest of the board is working. The external +5 volt supply must be regulated and the polarity must be correct. Double check this, as the DAC, MAX232, SIMM and laptop hard drive will be damaged if more than +5.5 volts is applied.
If the +3.3 volt power is bad, the problem is most likely a short circuit or failure somewhere in the circuitry that runs on +3.3 volt power. The LP2950 almost never fails, but it should be checked carefully to make sure it is inserted into the board correctly.
Many devices connect to the +3.3 volt power, so finding the short that prevents +3.3 volt power from appearing can be difficult. If you measure exactly zero volts, the problem is likely a solder bridge. If you see 0.5 to 0.8 volts, it is quite likely that a chip (such as the 74HC165) is inserted backwards. If something "strange" occurs on the +3.3 volt power, the FPGA is likely damaged.
Once you have correct +3.3 volt and +5 volt power, the next critical test is the MAX810 reset generator chip. This is a small surface mount part, and it can be difficult to hand solder. Unfortunately, it is even more difficult once the SIMM socket is soldered, so a bit of effort spent on good lighting and perhaps a magnifier is well spent. The MAX810 chip connects to +3.3 volts and ground, and has a single output that goes to the 8051 reset pin. This reset signal is supposed to be high for about 0.14 seconds after you turn on the power, and then it goes low and should stay close to zero volts. The 87C52 chip will not boot up without a proper reset signal.
If the reset signal is always high or always low, the soldering is likely bad. If it oscillates (appears as an "unstable" reading on most multimeters), the FPGA chip is likely damaged. This well-known FPGA failure involves the 87C52 beginning to boot up and when it reset the FPGA chip, the damaged FPGA shorts the +3.3 volt power, causing the MAX810 to detect the voltage loss and stop the CPU (which also removes the signal from the FPGA). If you see this problem, remove the FPGA chip and continue. If the reset signal is "stuck", (and the +3.3 volt power is ok) resolder or replace the MAX810 chip.
The boot up, the 87C52 chip requires +3.3 volt power, a valid reset signal, and the clock signal from the crystal oscillator. Failures in the crystal are rare, and it is difficult to test because probing the sensitive crystal signals can stop the oscillation (cycle the power if this happens). If you do test the crystal, an oscilloscope with 10X probe should be used. Without an oscilloscope, a visual inspection of the soldering and placement of the crystal, resistor and two capacitor is usually good enough.
When the 87C52 boots, it initializes some hardware and then transmits a welcome message at 19200 baud. What happens after this initial message depends on wether you send an 's' within 0.5 seconds (to stop it from executing firmware found in the flash rom), and of course wether the flash rom has firmware loaded in it. But regardless of the flash rom, the welcome message is always transmitted at 19200 baud, so you should first contrate on receiving this message in your PC's terminal emulator program.
The message is sent from the 87C52's TxD signal (pin 13), and it goes to a MAX232 chip (on rev C) which translates the 0 to 3.3 volt signal into a -10 to +10 volt signal to send to the PC. Actually, the MAX232 transmit voltages are typically about 9 volts, and they can vary a bit depending on your PC's loading of the line. But you should always see at least 7-8 volts.
If you can monitor the TxD pin, you can watch for the message before it gets to the MAX232 chip. This is tricky, because the message is relatively brief, so a sampling oscilloscope is probably the best approach. It is also possible to see a "blip" on an analog 'scope or a multimeter with reasonably fast update (hint: turn off auto-ranging).
The MAX232 chip has a small switched-capacitor power supply, and you can test if it is working by checking the DC voltage on pins 2 and 6 (relative to ground). Pin 2 should have approximately 9 to 10 volts, and pin 6 should have -9 to -10 volts. If you do not see these voltages, be sure to unplug your serial cable before you conclude the MAX232 is damaged, as a shorted or incorrect cable could load the MAX232 outputs down and reduce the voltage you see.
Common problems with serial communication involve incorrectly wired cables (a null-modem cable instead of a standard cable) and incorrectly configured terminal emulation software. Tests for these are described in other sections. Since you are troubleshooting at the hardware level with an unassembled kit, you probably will know if the board is transmitting the message and you just don't see it at the PC, but keep in mind that a null-modem cable or using the wrong serial port will appear as if the board did not send the welcome message.
Once you receive the welcome message on your PC, the board will no longer be a lifeless pile of electronic parts, and you can interact with it. At least you can if the return data path from your serial port to the RxD pin is working. Rarely is this a problem once the TxD path is working, but at least one kit assembly had this problem. The troubleshooting of the RxD path is similar... balance an object on your keyboard (to repetitvely send data to the board) and measure voltages from the serial cable, to MAX232 chip and ultimately the RxD pin. Again, trouble on the PC can appear to be a hardware failure on the board if voltages are not checked carefully and followed properly.
Once you can boot into PAULMON2, you can attempt to download a firmware image. The latest firmware images on the firmware page is usually the best choice. When the download has finished (or you press ESC), a summary of the download is shown. If errors occur, something is probably wrong with the flash rom or 74HC373 chip. A typical error will show that a very small number of bytes were written successfully. This is because the erased flash ROM contains all 1's (0xFF in every byte), and some bytes of the firmware are 0xFF. If the flash rom is not working, you can use the memory editor and hex dump commands to view and change the memory. If all locations are the same as the lower 8 bits of the address, the flash rom is probably not responding at all (check power, CS, OE lines, etc).
Most board-level failures to the flash rom (shorted address or data pins) result in the flash rom being unwritable. It always remains 0xFF no matter what you do. This happens because the writing proceedure to the flash rom involves operations that use all the address and data pins before the actual write occurs. Flash rom chips are designed this way to minimize the possiblity of accidental writes to the memory, but it also means that incorrect address and data connections usually result in the flash rom being unwritable. Less common problems involve duplicated data (you write to 0x2000 and the data appears at 0x2000 and 0x2400). These are usually due to shorted address pins.
Once you have successfully downloaded the firmware, you will be able to get much more information about any remaining problems. Of course, everything might just work perfectly, but if it doesn't.....
First, you can run the board with or without a SIMM installed. If you run without a SIMM, the 0.6.x firmware should detect that no memory is installed and it should run the older 0.1.x firmware that does not use the SIMM. If you have trouble, it is best to focus on running without a SIMM first.
TODO: errors with hard drives, and bad connections to IDE/SIMM, often FPGA is easily damaged
TODO: running the simm test utility
TODO: audio problems with STA013 crystal and PLL (strange sounds)
TODO: audio problems with DAC (no sound at all), what the 4 waveforms should look like
TODO: audio problems with analog circuits (usually only one channel messed up)
Corrupted Firmware, Can't Erase Flash ROM
>I was loading the latest upgrade when the power went out near the end of
You need to get to the PAULMON2 prompt and use the 'Z' command to completely erase the flash rom. Then you can download new code.
To do this, you need to press 'S' at a certain point while the player is booting up. The easiest thing to do is just hold the 'S' key down and let your keyboard's auto-repeat send a stream of S's as the player boots. Press and hold the 'S' key before you apply power, and keep it down until you get the prompt. If you need to use both hands to remove/apply power to the board, then have someone else hold the 'S' key or balance an object on the 'S' key to keep it down.