I have a Cypress hub (CY7C65634) connected to a Cypress FX3 (CYUSB3014) by means of a Maxim SPI-to-USB bridge (MAX3421E). The hub seems to be reseting correctly, and receives control transfers without error. However, when I try to retrieve the descriptor via a BULK-IN transfer (as specified in MAX3421E datasheet), I am greeted first with a NAK, and subsequently by J-STATE. NAK seems to indicate that no data is available to send. Do you know of any reason why the hub has not prepared the descriptor?

I've attached my code FWIW, though it may require some familiarity with the MAX3421E. Any help would be appreciated.

<code>

void configureUsb(void){

/*The CPU sets this bit to instruct the SIE to issue a bus reset on the D+ and D- lines. After setting this bit, the CPU can detect the end of the 50ms interval either by polling the BUSRST bit for zero, or by responding to the BUSEVENTIRQ. To program a bus reset, follow this sequence of steps:

1. Set BUSRST = 1. 2. Test for BUSRST = 0 or respond to the BUSEVENTIRQ. 3. Turn on frame markers by setting SOFKAENAB = 1. 4. Wait for at least one FRAMEIRQ. Step 4 ensures that the host logic is ready to generate the first host transaction. */ dragonDebug("configuring", 100);

uint8_t error = 0; /* 2. Data If a data stage is required, it is programmed as a BULK-IN or BULK-OUT transfer. Some CONTROL transfers, such as Set_Address, do not require a data stage because the command data fits into the 8 bytes in the SETUP packet. */

/* * Programming BULK-IN Transfers * The CPU issues an IN token to request a peripheral to send it BULK data . Then the SIE * transfers data into its RCVFIFO, and ACKS the transfer. The CPU writes HXFR = 0000eeee * (Table 4) to initiate the IN transfer, where eeee is the desired endpoint address. * */

maxWriteReg(rPERADDR, addr); maxWriteReg(rHXFR, endpoint & 0x0F); /* The SIE sends an IN token, the address in the PERADDR register, the endpoint number in EP[3:0], and a CRC5. It then waits 6.5 bit times for the peripheral to respond. If the peripheral responds with a DATA0 or DATA1 PID followed by data, the SIE loads the received data bytes into the RCVFIFO and counts the bytes. At the end of the packet the SIE checks the packet for errors, updates the RCVBC register and HRSLT bits, and then asserts the HXFRDNIRQ bit. */

// clear completion interrupt maxWriteReg(rHIRQ, bmHXFRDNIRQ); /* Depending on the transfer outcome, the SIE may or may not assert the RCVDAVIRQ. If the IN data was error-free (HRSLT = 0000), the SIE sends an ACK token, complements the data toggle, and asserts the RCVDAVIRQ to indicate that new IN data is valid. If the IN data was error-free but there was a data toggle mismatch (the DATA0 or DATA1 PID send by the peripheral did not match the endpoint toggle value), the SIE sends the ACK handshake, but it does not complement the data toggle or assert the RCVDAVIRQ. The SIE sets HRSL = 0110 (Toggle Error) for this condition. This situation would happen if the peripheral received a corrupted ACK handshake from the previous IN transfer. In this case the host ignores the data in the RCVDATA FIFO, because it represents data that the peripheral mistakenly resent when it missed the last ACK handshake. By ACK-ing the transfer and not updating its own toggle bit, the SIE causes the peripheral to complement its toggle bit, thus forcing the data toggle mechanism back into sync. If the HRSLT bits indicate a data error, the SIE does not send the ACK, complement the data toggle, or assert the RCVDAVIRQ bit. The CPU responds to the HXFRDNIRQ indication by examining the result bits in HRSLT[3:0]. If the result is 0000 (success), the CPU reads RCVBC to determine the byte count, and then reads that number of bytes using repeated reads to the RCVFIFO register (page 48). After the CPU retrieves the data, it clears the RCVDAVIRQ bit (by writing 1 to it). If there is another buffer of IN data in the double-buffered RCVFIFO, the SIE immediately re-asserts the CVDAVIRQ bit. */

Control transfers are used for enumeration of the device/hub by the host, using Endpoint 0 only with default address 0. The host will send a request to Endpoint 0 of device address 0 to find out the device/hub capabilities. This request is the one to which the device must respond on address 0. After that the device/hub will get an unique address on which it responds to the host requests further. So, we should not expect the control transfers for enumeration to happen through BULK IN transfer which is for data transfer.