Troubleshooting Arduino USB Host Shield

Making electronic devices requires close interaction with parts – reversing supply polarity, overloading inputs, and inadvertently shorting pins with test leads. Consequently, occasional destroying of parts is natural and shall be anticipated. I have been in correspondence with several electronics enthusiasts helping them getting their shields fixed and since their problems look similar to what I see when doing post-manufacturing quality control I decided to share my testing procedure along with some pictures.

In the past, it was customary to include schematic with every electronic device documentation. Complex devices, such as oscilloscopes, spectrum analyzers and other test instruments used to have service manuals containing detailed calibration and repair procedures. At some point, service manuals and schematics disappeared from the documentation for various reasons – equipment users were left to deal with manufacturer’s support or rely on their own reverse engineering skills. With open source movement and general understanding that sharing information is beneficial, manufacturers resumed publishing schematic diagrams of their creations. This article presents next logical step – a service manual for Arduino USB Host Shield, sort of.

Much of the testing is performed using board test sketch, available from examples section on github. Two files are necessary – board_test.pde and board_test.h containing diagnostic messages. The sketch tests 4 major parts of the circuit – SPI interface, general purpose input/output pins (GPIO), quartz crystal oscillator, and finally USB SIE. The main loop is written so that any test can be turned off if necessary by commenting out a single line. GPIO lines are checked using a loopback adapter – a thing that connects GPIN0 to GPOUT0, GPIN1 to GPOUT1, and so on. This test is made optional – if you don’t connect GPIO lines as described, the test will print an error message and continue with the next test. Also, GPIO test is placed between short and long SPI tests. The reason for this is that due to MAX3421E internal organization both short SPI test (reading REVISION register) and GPIO read/write doesn’t require working crystal oscillator, whereas long SPI test (reading/writing any other register) will fail and stop if crystal is defective. Therefore, when I see short SPI and GPIO tests passed and long SPI test fail I know that it’s actually a crystal which is dead, not SPI.

In addition to board test program, you will need a multimeter with thin sharp test leads to measure voltage and resistance between board elements. Some of them are quite small so a magnifier is also handy. Certain steps of the test procedure call for time-base instrument. Modern digital mixed-signal oscilloscope is the best choice, however, since very few people can afford one, a method of visualizing SPI traffic with plain analog oscilloscope will also be demonstrated. Logic analyzer is handy, but optional. For testing USB transactions you will also need some sort of device connected to shield’s USB connector. I usually use USB flash drive as a test device.

The article as well as board test program is written for worst-case scenario, i.e., shield which was built from scratch or came from major rework like MAX3421E replacement due to applying 5 volts to 3.3V pin. The test program works the same way with all four configurations, however, manual tests are shown only for “Simple” configuration, i.e. one with level translators and receiving both 3.3V and 5V from Arduino Duemilanove or similar (no DC-DC converters). Testing other configurations is slightly different and will be noted in the text. Also, “Minimal” configuration calls for specific type of test device – I use digital camera.

Before plugging shield into Arduino it’s good idea to do a quick check of power traces. Resistance from ground to 3.3V pins of the shield should be about 200KOhm, ground to 5V – more than 1MOhm. If yours is measuring much less than that, find out why. Usually, resistance of less than 1KOhm means that MAX3421E was soldered in wrong orientation. Resistance less than 100Ohm means that there is a short somewhere. Soldering mistakes and shorts would have to be fixed before we can proceed.

The resistance figures given above are different for other configurations. For example, 5V shield measures 500KOhms 5V to ground and voltage from multimeter actually starts the DC-DC converter so results of a measurement look rather strange. Exact numbers are not important – by measuring power line resistance we are making sure that no shorts or inverted tantalum capacitors exist on a power trace.

Board test sketch starts checking the shield by reading die revision register from MAX3421E – there are only 3 values which are accepted, 0×01, 0×02, and 0×03. Shield with shorted or unpowered SPI returns either 0xff or 0×00. If this test passes, I can conclude that MAX3421E and level translators are receiving power and SPI lines are kind of OK. However, if this test fails, more measurements are required. First thing to check is power to active elements of the circuit. Picture on the left shows measurement points and voltages. IC power pins and bypass capacitors are highlighted. When testing, I’m measuring on the IC pin rather than the cap and try no to short power pin to the adjacent one. If probing IC pin is not possible, measure on the capacitor but check with good magnifier that solder joints are solid. If power is absent in any of the test points, check power coming from Arduino and DC-DC converters, if any.

If ICs receive power but test still fails, SPI lines need to be checked. To help with this check, board test routine starts generating SPI transfer of 0×55 (binary 01010101, i.e. alternating 0 and 1). Other necessary signals are also generated. First signal to check is SS. By default it comes from pin D10 of Arduino connector; right probe on title picture is probing this very pin. It is 5V p-p square wave signal with ~12uS period (on Duemilanove or other 16MHz Arduino). If you can’t see it with an oscilloscope, it’s either shorted or Atmega pin is dead. To isolate the fault, disconnect power from Arduino, pull the shield out of Arduino, apply power and restart the test. When it fails at SPI test, repeat the measurement. If you still can’t see SS, try two other SPI signals generated by Arduino – SCLK (pin D13) and MOSI (pin D11). If you can see them but not SS, the Atmega pin may be fried. If neither of signals could be visualized, check your probing setup and also make sure board test sketch is still running. It is highly unlikely that all 3 pins are dead so before replacing Atmega chip on Arduino board make sure that your oscilloscope is functional.

If SS signal is present, it can be used as a trigger to see the rest of SPI lines. SS gets connected to the external trigger input of oscilloscope’s horizontal sweep and time base is set to trigger on negative-going slope. Picture on the left shows how signals, probed on the Arduino connector, look like on an analog oscilloscope with 20MHz vertical bandwidth. Click on a picture to make it bigger. Left shot in the top row shows SS (bottom trace) and SCLK, triggered by negative-going slope of SS. In the middle shot, still triggered by SS and slightly stretched, bottom trace shows MOSI signal against SCLK. It is possible to read what is being transmitted – the state of MOSI at positive-going edge of SCLK gives you transmitted bit. It can be seen that counting left to right first low to high transition of SCLK lies against low state of MOSI, second against high, third – against low, and so on, giving 01010101, or 0×55.

The right shot in top row shows MISO signal against SCLK, i.e., MAX3421E transmitting it’s status. You can try reading what is being transmitted on MISO using technique given above or just look at the screenshot in the bottom row of the same picture showing Intronix Logicport analyzer output of the same signals – all at once with protocol decoding. However, logic analyzer can be used only when signal integrity is checked with oscilloscope, otherwise it’s output will be difficult to interpret.

If your MISO is similar to the one on the picture, SPI is working. If MISO is constantly low or high and other signals look distorted or amplitude is wrong, check signal path from Arduino pin through level converter (amplitude will go down to 3.3V) to MAX3421E. It is very important to use correct schematic diagram for the revision of a shield. Shield revision 1.0 has level converters in DIP packages, revision 1.2 has SOIC level converters and schematics are different. If MAX3421E receives clean SCLK, MOSI, SS, MAX_RESET is high and power on pins 2 and 23 is within spec, MISO shall be transmitting status looking similar to one on the picture. If it’s not seen on pin 15 of MAX3421E, check to see if this pin or MISO trace is shorted to the adjacent one. When all connections are checked good, the last option is to replace MAX3421E.

I already noted that test program will fail a second SPI test when quartz oscillator is not working. However, if you can see clean MISO signal similar to one pictured, it means that SPI is OK. Oscillator can also be checked with oscilloscope. Look again at the picture showing supply voltages. Pins in the top right corner of MAX3421E, 24 and 25, are connected to the quartz crystal. When oscillator is working, 12MHz 3-4V p-p sinewave signal can be observed on either one of them. For this measurement FET probe is essential; ordinary passive 10x probe introduces relatively large capacitance and can stop oscillator altogether. The “OSCOKIRQ failed to assert” message in the first line of test sketch output is also a good indicator of faulty oscillator. The best way to fix it is to replace the crystal.

The last test is a short sequence of USB transactions resulting in getting device descriptor from the connected device. If test fails or stops at “Waiting for the device” message, it means that either USB D+ and D- lines are faulty or VBUS power is not present. Both faults can easily be found with a multimeter. Errors reported during other stages could mean many different things, including, again, faulty oscillator, bad connection, or simply polling of device too rapidly. Good example of false error is Error code D or 0d just before printing device descriptor. In any case, successful output of device descriptor means that shield is fully operational.

The test routine described here has been working as post-production test for quite some time and and shows good results. Give it a try and tell me what you think.

Oleg.

Related posts:

1. Arduino USB Host Shield build log. Part 4.
2. Arduino USB Host Shield build log. Part 1.
3. USB Host Shield for Arduino – first prototype.
4. Arduino USB Host Shield build log. Part 2.
5. Arduino USB Host Shield build log. Part 3.
6. PS3 and Wiimote Game Controllers on the Arduino Host Shield: Part 1
7. Towards an FT232 Driver for the USB Host Shield- Part 0
8. PS3 and Wiimote Game Controllers on the Arduino Host Shield: Part 2
9. PS3 and Wiimote Game Controllers on the Arduino Host Shield: Part 3
10. Arduino USB host – First programs.