Bringing Up a MAX3420E System
IntroductionYou designed a board with the MAX3420E hooked to your favorite microcontroller. You fire it up, plug into USB, and...nothing. What now? Read on.
Bringing up a USB peripheral device for the first time can be a challenge. Following is a checklist of details that need to be right before the MAX3420E has a chance to work correctly.
Verify the USB 'B' Connector PinsThis is surprisingly easy to do wrong. Was that part drawing a top or bottom view? Where is pin 1? If you are not a mechanical engineer, those parts drawings can be confusing. Figures 1 and 2 will help you.
Figure 1. Looking into the USB B connector.
Figure 2. Orientation of the B connector pins, seen from the bottom of the PCB.
Figure 3. USB cable wire connectors.
It is a good idea to check the wiring from the MAX3420E to the USB connector with an Ohmmeter. Pay particular attention to D+ and D-. It is easy to get these reversed. Remember that there are 33Ω resistors between the MAX3420E and connector D+ and D- pins. Most continuity checkers will still "beep" with this low resistance. If you ever need to probe a USB cable, Figure 3 will help.
USB 'Sanity' CheckThis section explains what happens when you connect your device to USB. The sanity check shows what is happening on the D+ and D- wires, which should be useful if you do not have access to a USB bus analyzer.
Reset your processor, connect a cable to a PC USB port, step your code past the initialization, and stop just before the statement that sets the CONNECT bit. This statement should look something like this:
wreg(rUSBCTL,bmCONNECT); // Connect to USBBefore executing this statement, both D+ and D- should be low. This is because circuitry on the cable's host side pulls these signals to ground with 15kΩ resistors. Now, when you step through the CONNECT statement, you instruct the MAX3420E to connect an internal 1.5kΩ resistor between D+ and VCC (3.3V). You should see D+ go high, followed by little bursts of pulses (Figure 4).
Figure 4. When you set CONNECT = 1, D+ goes high and little bursts of activity appear.
The top trace is D+ and the bottom trace is D-. The bursts last for about 18s then they disappear. D+ stays high and D- stays low, and this little Windows XP message pops up (Figure 5):
Figure 5. Windows XP alert message.
What is happening?
Remember that we are single-stepping the code. All we did so far was to connect the D+ pullup resistor. This pullup alerts the PC that a new USB device just plugged in, so the PC starts sending signals to the device to determine what it is. Those are the blips in Figure 4. Since the microcontroller code is not running, it never commands the MAX3420E to send back any responses. The PC notices the lack of response, and finally (after 18 seconds) decides to ignore the device. The bus state of D+ high and D- low is known as 'USB bus suspend' or just 'suspend.' The host stops sending any signals, and the MAX3420E's D+ pullup resistor keeps the D+ signal high.
Figure 6. Illustration of what is happening on the bus (NAKs hidden).
Figure 6 is a bus trace taken with a USB bus analyzer from LeCroy Instruments (LeCroy acquired CATC, the original manufacturer of the analyzer). When the PC senses the plug-in event (CONNECT = 1), it issues a USB bus reset (not shown). Then in Transfer 0, it sends out a request called, "GET_DESCRIPTOR" of type "DEVICE." After 5.687s, the PC issues a second USB bus reset, trying again for 5.578s to get a device descriptor. The PC resets the bus a third time, tries for another 5.580s, then gives up by suspending the bus. Since the firmware is not running, nothing is listening to, or acknowledging (ACK) the PC's requests.
Figure 7. This is Figure 6 with the first transfer expanded to show packets and NAK handshakes.
For clarity, the Figure 6 trace suppresses NAK (Negative Acknowledge) handshakes sent back by the MAX3420E. Figure 7 expands the first transfer to the packet level to show a bit more detail. Now you see that Transfer 0 begins with three packets:
- The host sends a SETUP packet (63) addressed to the just-connected device (USB sends address 0 for this situation).
- The host sends a DATA packet (64) containing an 8-byte "op-code."
- The peripheral (the MAX3420E) sends back an ACK packet (65) to acknowledge error-free receipt of the two host packets.
Next, the host starts sending IN requests starting with Transaction 1. Each IN request is greeted by the NAK (Negative Acknowledge) handshake from the MAX3420E. This is because the program is not running and, therefore, the microcontroller attached to the MAX3420E never sees the SUDAV IRQ (Setup Data Available Interrupt Request).
Note: the MAX3420E alerts the microcontroller that a SETUP packet arrived by asserting the SUDAV IRQ. This informs the microcontroller that it needs to decode the packet data and respond by sending back the requested data.
These IN-NAKs go on for 5.687s, at which time the PC resets the bus and starts its second try. The little blips you see in Figure 4 are the IN-NAKs. If you watch the scope closely, you will see the pattern change slightly after about 5s—this is the bus reset (about 30ms of both D+ and D- low) followed by another SETUP packet. Then the IN-NAKs continue for another 5s.
FYI: Another Analyzer
Figure 8. The Beagle.
You may not have the budget for a USB bus analyzer like the one that produced Figure 6 and Figure 7. Although this application note assumes that you only have a scope and Ohmmeter, we strongly advise that you get a USB bus analyzer for your USB development work. The LeCroy/CATC that we used has the advantage of a beautiful interface, lots of software, and, most importantly, the reputation as the industry-standard USB measurement tool. Many arguments (hardware, software, chip, etc.) have been settled by exchanging CATC traces to prove exactly what is going on. The bus does not lie.
Fortunately, low-cost USB analyzers also are available. Figure 8 is a screen shot from the Beagle-USB. The Beagle analyzer shows bus traffic at a fraction of the LeCroy/CATC price. If you compare Index 10 in Figure 8 with Packet 64 in Figure 6, you will see that they display exactly the same data in the SETUP packet.
Checking Your ProgressIf you see the signals in Figure 4, you have verified that the USB connector is wired correctly and that the MAX3420E is correctly powered. If you do not get this far, here are a few things to try:
- Probe the MAX3420E RES# pin and verify that it is HIGH.
- Probe the crystal and insure that it is oscillating at 12MHz. It must be 12MHz ±0.25% to meet the USB specification. If it is out of tolerance, make sure that you have the correct load capacitors as specified for the parallel resonant crystal (18pF is a common value).
- Check VCC for 3.3V.
- Check VL for your system interface voltage. Make sure this is not higher than 3.6V.
- If you are powering the MAX3420E VCC pin from VBUS by a 3.3V regulator, make sure that you are connected to USB. Otherwise, the MAX3420E is getting no power on VCC.
Note: It is easier to debug a self-powered design than a bus-powered design, since the firmware runs whether or not the USB cable is attached. It is a good idea to power your prototype using an external supply. If necessary, you can convert it to bus power later.
The next step verifies that your controller is successfully talking to the MAX3420E register set over the SPI bus.
Verify rreg() and wreg().Any code you write, whether you use Maxim's example code or start from the beginning on your own requires functions to read and write the MAX3420E registers. The examples below use these function prototypes:
unsigned char rreg(BYTE r); // Read a MAX3420E register byte void wreg(BYTE r,BYTE v); // Write a MAX3420E register byteBefore attacking code that services USB transfers, write a simple routine to test these functions. See Figure 9 as an example:
Figure 9. Single-step and examine "rd" eight times to verify the SPI interface to the MAX3420E.
The test code in Figure 9 resets the MAX3420E, and then writes eight bytes consisting of a walking-one pattern to the USBIEN register. Each byte has one bit set, starting with 00000001, then 00000010, and ending with 10000000. Single-step through this function and inspect the value of "rd" eight times, confirming that they are 0x01, 0x02, 0x04, 0x08, 0x10, 0x20, 0x40 and 0x80. If so, you confirmed both register write and read operations over the SPI interface. If you can write the USBIEN register and reliably read back its contents, you can write and read all MAX3420E registers.
Figure 10. Single-stepping and inspecting a variable's value using Rowley CrossStudio for the MAXQ2000 microcontroller. Place the cursor over "rd" and its value pops up.
Figure 10 is a screen shot of a debug session using CrossStudio. for the MAXQ2000 microcontroller. The popup window is activated by placing the cursor over the "rd" variable. (The screen shot does not display the cursor.) Any variable can be inspected this way while single-stepping through the code.
The test code begins by setting up the microprocessor SPI port. The SPI_Init() function will vary for each microprocessor type and specific IO pin assignments. Then the code sets up the MAX3420E SPI interface for full-duplex operation by writing the PINCTL register with the value 0x10. This sets the FDUPSPI bit. The code then puts the MAX3420E into a known state by asserting the CHIPRES bit and then deasserting it. It is advisable to include a chip reset at the beginning of the code to put the MAX3420E into a known state at the beginning of every debug cycle.
If the code in Figure 10 does not produce the correct result, you should inspect the SPI signals to verify their operation.
Figure 11. Executing the first wreg() call.
The first call to wreg() in the test program, test_SPI(), writes MAX3420E register 17 with the value 0x10. The SPI bus traces should look like those in Figure 11.
Note: The traces shown in Figure 11 use SPI mode (0,0), where the SPI data is sampled on the rising edge of SCLK, and the quiescent SCLK level is low. Your trace may have different pulse durations, depending on the SPI interface, but the values shown at the SCLK rising edges should be the same.
The first byte of every SPI access is a command byte that follows the format shown in Figure 12. Looking at the Figure 11 MOSI trace during the first SLCK rising edges, we see the bit pattern 10001010, indicating register 17 (bits 7-3 are 10001, the value 17). Also, bit 1 is high, indicating a write operation. The second byte shows the bit pattern 00010000. This is the data written to register 17, which is 0x10 (only bit 4, the FDUPSPI register bit, is set). Therefore this SPI access writes register 17 with 0x10, which sets the FDUPSPI bit.
Figure 12. The MAX3420E command byte format.
An easy way to capture these traces is to set the scope or logic analyzer to trigger on the falling edge of SS#, then single-step through the wreg() calls.
Figure 13. First write to USBIEN register (test_SPI() function).
The next statement in test_SPI() checks the rreg() function. The first time through the loop the value 0x01 is written to the USBIEN register, as seen in Figure 13.
Figure 14. First call to rreg() function.
The test_SPI() function then reads back the value of the USBIEN register, which for the first pass through the loop should be equal to 1 (Figure 14). Each time through the loop the written and read-back bits should move one SCLK edge to the left.
After the MAX3420E register writes and reads are verified, the code can be debugged further. All checkout steps up to this point have been in the 'sanity check' category. Now we take the first step into actually handling USB traffic: we respond to the various MAX3420E interrupt request bits signaling that processor attention is required.
Initial IRQ Bit SettingsIt may seem logical that MAX3420E interrupt bits assert only after USB bus traffic starts. Actually, some IRQ bits assert when you power up the MAX3420E, and others assert when you plug in the USB cable and when you set CONNECT = 1. The following section gives an overview of what to expect during this startup sequence.
Out of RESETWhen you take the MAX3420E out of reset, certain interrupt request bits assert, even if you are not yet connected to USB. These bits are:
Note: The MAX3420E IRQ register bits are active whether or not their associated enable bits (in the EPIEN and USBIEN registers) are set. The enable bits determine if the request bits get passed on to the logic driving the INT pin. See application note 3661, the MAX3420E Interrupt System, for more details.
After USB Plug-InAdditional USBIRQ bits assert when you plug into USB (with CONNECT = 0) even though there is no USB traffic. The EPIRQ bits remain the same as in the above section, but more USBIRQ bits may assert:
- VBUSIRQ (maybe)
Note: Connecting the VBUS pin on the USB connector to the MAX3420E VBCOMP input pin is optional. The VBCOMP pin powers nothing inside the MAX3420E. It is routed only to the internal VBUS comparator.
After Setting CONNECT = 1Connecting to USB causes the host to issue a bus reset, generate the Get_Descriptor-Device request, and eventually suspend the bus. These actions set additional IRQ bits in the USBIRQ Register. Note that the USB bus reset clears the VBUSIRQ bit.
- SUDAVIRQ (after traffic starts)
- SUSPIRQ (eventually)
What happens from here on will depend on your code. If you observe everything as stated above, you can continue to check out your code with good confidence that the system is in good order.