Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

USB - MAX3421e Enumeration Transfers

Status
Not open for further replies.

MBrej

Newbie level 4
Newbie level 4
Joined
Jul 15, 2009
Messages
5
Helped
0
Reputation
0
Reaction score
0
Trophy points
1,281
Activity points
1,355
max3421e

Hi, Im implementing the MAX3421e in host mode with a small microcontroller, and using the maxim C code for guidance. Ive managed to transfer the detect device and detect device removal routines for my microcontroller, and now need to write the enumeration routine. The first step is to send 'Get_Descriptor_Device' and get the first 8 bytes from the peripheral, while it is still on the default bus address of 0. After that the host sends the command to move the device to a unique address, and continues to query the device.

The problem I have is after sending commands to the device, the MAX3421 writes the HRSL register with the result of the transfer, and this result reads back 0x0D (hrJERR - J-state instead of response), and then 0x05 (hrSTALL) when tokens are sent (presumably the device didnt think much of the 'Get_Descriptor_Device' command). There is a similar response to trying to change the address, and then when the address has attempted to be changed, there is absolutely no response on the new address, any control transfer only gets 0x0D as the result, and never 0x05 (hrSTALL), presumably the device has not changed address.

I am fairly sure i have correctly implemented the code using the maxim example, I am confident my SPI routines work as I can control the IC fine, but I have not been able to find why the result of the transfers is always hrJERR (for the main control command transfer) and then hrSTALL for tokens (such as tokIN and tokINHS) sent to complete the transfer. If anyone would know what causes this result and what may be the problem, help would be much appreciated.

Thanks, Matt
 

hrjerr

if your following the maxim code, then your likely performing a device reset once you've configured it's SPI interface.

upon attachment of your device, are you configuring high or low speed?

first step following attachment is to reset the USB bus, followed with some delay.

at this point your device must respond on the control endpoint if sent compatible requests. J state error at this time could possibly be wiring issues. Stalls are most likely non compatible requests.

double check your speed configuration. Are you sensing the appropriate high/low speed and making the appropriate configuration (implying a D+/D- swap)

12 mhz xtal right?
 

enumeration in usb

one more thing I forgot is that I've found transfers will fail when Max's supply voltage falls below 3volts, although it's gpio will still work down to about 2.7v
 

max3421e circuits

Thanks, just to answer some of your ideas, when a device is attached it is correctly identified as low or high speed, and when a low speed one is detected the bit LOWSPEED is set in the mode register. The D+/D- wires are the right way round (I get error codes in the HRSLT figure when I decided to see what switching would actually do). The crystal is 12MHz, although I have no way of testing the frequency, but I have swapped it just in case. I would expect the MAX3421 to not even receive STALL if the crystal was incorrect. The MAX3431 is also powered by a 3.3V regulator, and Im sure the voltage isn't dropping as the micro would die also.

While trying a few things, I noticed that USB memory sticks (devices without long leads on them) would return SUCCESS codes, although this was also at a time when I was adding and removing code to set the RCVTOG1/RCVTOG0 data toggles before different transfers, although going back to the original code (as copied from the MAXIM examples), USB memory sticks do produce very few errors, compared to even memory sticks on a short extension lead. I have only been testing with high speed devices though.

At the moment I have a PCB A socket where I plug devices into, which is then connected to the test circuit with 4 short flying wires, although I did twist the data ones. The 33Ω series resistors are soldered to the end of these, which briefly go into a breadboard before the connecting to the MAX3421. From what I have found it would appear that maybe there are some issues here, which maybe causing problems. Could capacitance in the breadboard reduce the length of leads without error somehow, and perhaps unshielded (although twisted cable)? It also maybe a good idea if I looked into the DATA0/1 toggles, although I cant see how that would cause an issue if I followed MAXIM's example. I am aware that the toggles work in different ways for SETUP transfers.

Thanks again, Matt
 

usb max3421e

as long as you remain with the same endpoint, toggle will sync. It's when you move to another endpoint that you have to save and restore toggle status.

If you've had some success with some devices, you should be good on the control endpoint at least. I keep the resistors close to the device, but from there I've had some pretty wonky leads, without problem.

Looking at my code, I see I've used Maxims right up to set_address.[/code]
 

max3421e program

Ive been trying a few more things, and it does appear the length of wire after my connector makes all the difference. I was testing a device on the end of a extension lead, and I was getting J-state errors as usual, then when I disconnected the device from the end of the extension lead, the MXA3421 kept returning J-state errors. However, when I unplugged the extension lead from my socket, the MAX3421 then gave a TIMEOUT result.

I have now reduced the length of the wires between the max3421 and the socket, and connected the shield of the socket to ground, but I still get the same result.

You said that the 33Ω resistors should be as close to the device as possible, although how is this possible when the device you are connecting has long lead on it? How essential are these resistors anyway?

Thanks, Matt
 

max3421 endpoint 0

your USB electrical specs call for an allowable line impedence. In combination with your line driver, these resistors control the line/driver impedence. Thier placement is not necessarily critical, but for the Max line drivers, need to be at the host end of the cable.

What are you using for cabling? Does it meet the USB spec?. You should be using a standard USB cable. I have used short runs (under 10") to connect the Max port/terminating resistors to the USB connector without problems.

What are you using for PLL components?
 

swap d+ d- enumeration

I found a USB extension cable I didn't want and connected it to the circuit as this cable would meet the usb spec. However, the results are still similar to the previous arrangement. I have attached an image of the arrangement, and I was wondering if anyone could see any problem with the arrangement. The usb cable is about 30-40cm long.

Thanks, Matt
 

max3421e hrjerr

circuits with that much residual resin is going to be a problem at frequency.

I'd scope your xtal looking for skew. If that's ok I'd then program in an SOF marker and scope that, again looking for excessive skew.
 

max3421e sample code

Go to my site, there is plenty of info and sample code for MAX3421E. You can also post your code here.
 

teste max3421e

Sorry i havnt posted recently, I havnt been around to try things with the circuit. I am fairly sure the oscillator is fine as it would not work for devices with a short lead otherwise? Also I have had two different crystals attached to it, one of which was one from an old motherboard, and the two capacitors as well, so the capacitors must be fine for the crystal. I dont have any way to measure the frequency of the crystal, and im guessing an oscilloscope may affect the crystal anyway?

@felis_CO I have already seen your site, and i dont think coding is an issue. My micro is a PICAXE, and so written in a basic sorta language, and I can post it if you think it may be helpful, but due to the language it will not be as tidy as a C based language.

I think the problem is due to the impedance of the data line somehow, and it may be a good idea to make a new test board with a A socket on the board. I have cleared the flux residue and still the same.

Thanks, Matt
 

max3421 com port

are you able to program and view an SOF marker?
 

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top