5. How do I know when to load an IN FIFO?
The MAX3420E provides interrupt request bits for the IN endpoints called IN3BAVIRQ, IN2BAVIRQ, and IN0BAVIRQ,
where "BAV" indicates "Buffer Available". The MAX3420E logic sets an IN endpoint BAVIRQ bit after a device reset,
or when IN FIFO data has been successfully transferred and acknowledged by the host. At power-on, the BAVIRQ
bits are set to indicate that the IN FIFOS are initially available for loading. These are the only register bits that are set
to 1 by a reset—all the rest are set to 0.
6. What if there is a USB transfer error? Do I need to write code to handle the error condition?
No. The MAX3420E manages this for you. If the MAX3420E receives an error condition back from the host, it
automatically resends the same data when the host retries the IN transfer. The MAX3420E also automatically handles
other error checking such as data toggles. Some possible USB errors (such as a user unplugging the cable in the
middle of a data transfer) need to be handled by firmware.
7. How do I program a BULK OUT transfer?
When the host sends OUT data, the MAX3420E stores the bytes in an OUT endpoint FIFO. After the transfer is
complete and verified to be error-free, the MAX3420E asserts a "DAV" (Data Available) interrupt request bit for the
particular endpoint. This alerts the SPI controller to read the FIFO bytes. The SPI controller first reads an OUT FIFO
byte-count register to determine how many bytes in the 64 byte FIFO are valid. It then reads that number of bytes by
repeated reads to the OUTFIFO register. Finally, the SPI controller clears the OUT DAV IRQ bit (by writing 1 to it) to
"rearm" the endpoint for another OUT transfer.
8. How about INTERRUPT transfers?
Interrupt transfers are programmed identically to BULK transfers. They differ only in how they are described in the
device descriptors sent back to the host during enumeration.
9. How do I program a SETUP transfer?
The USB host uses a CONTROL transfer to send a SETUP packet to the MAX3420E along with eight bytes that
serve as a USB "op-code". The MAX3420E stores these bytes in an 8-byte FIFO, and then asserts a Setup Data
Available interrupt request. The SPI master responds by reading the eight SETUP bytes at register address R4
(SUDFIFO), interpreting the USB request from these bytes, and taking the appropriate action. When finished servicing
the request, the USPI master sets a bit called ACKSTAT (ACK from acknowledge, STAT from STATUS stage) to tell
the MAX3420E to acknowledge the status stage of the CONTROL transfer.
10. Do I need to program the USB data toggles?
No. The MAX3420E handles these toggles automatically during USB transfers. The only time firmware might need to
intervene is when the host sets a new configuration in a multiconfiguration design (these are rare). The MAX3420E
has register bits to clear the endpoint toggles for this purpose.
11. The MAX3420E interrupt request bits are cleared by writing "1" to them. Is this backwards?
It may seem backwards at first, but it is the most efficient way to clear a register bit. To service a typical interrupt
request, the SPI master reads an interrupt request register (either USBIRQ or EPIRQ), and checks using various bit
masks to determine the source of the interrupt. For example, to test for the SUDAVIRQ interrupt request, firmware
would read R11 (EPIRQ) and AND the result with 00100000 (the SUDAVIRQ bit is in the bit 5 position). Typically a
program will equate a label like bmSUDAV with 0010000. Once the IRQ bit is detected to be a 1, the firmware can
simply write the mask value back to the register (SUDAVIRQ = bmSUDAV) and only the desired bit is cleared. IRQ
bits written with a zero are unchanged.
12. Do you have any programming tips?
When using the SPI full-duplex mode, the very first register access should set the FDUPSPI bit to 1 in order to
correctly set up the interface for subsequent accesses.
5. Host Software Questions
1. How does my Windows® application talk to the MAX3420E?
A Windows® application talks to the PC's USB host controller through a driver. The driver may be built into Windows
or it may be custom. Windows includes built-in drivers for standard device classes, such as Human Interface Devices
(HID) and Mass Storage Devices. If your firmware supports one of these standard classes, your customer does not
need to load a custom driver.
If you are designing a device that does not conform to one of the built-in Windows standard device classes, the end
user must install a custom driver when your USB device is plugged in the first time.
