BF533 / ISP1761 USB Host enumerating problem

(Updating the thread...)

This week I discovered some things.

The words of the GetPortStatus were not being interpreted correctly. Endianess problems and misinterpreted casts from compiler.

Well, now I can enumerate the internal hub and see the PortStatus flowing as it should be.

Below is the dump from my program:

GetDeviceDescriptor: address:0 | size:8 GetDeviceDescriptor: address:2 | size:18 SetFeature PORT_POWER on port 1 SetFeature PORT_POWER on port 2 SetFeature PORT_POWER on port 3 GetConfigurationDescriptor address:2 SetConfiguration 0x1 address:2

GetPortStatus: wPortChange[0001] wPortStatus[0101] (Now it is represented correctly)

ClearFeature C_PORT_CONNECTION on port 2 SetFeature PORT_RESET on port 2 GetPortStatus: wPortChange[0010] wPortStatus[0103]

ClearFeature C_PORT_RESET on port 2 GetPortStatus: wPortChange[0000] wPortStatus[0103] DW1 data: Token:SETUP | EPType:CONTROL | Addr:0 | Endp:0 GetDeviceDescriptor failed

PTD Error: DW3: 5240_0000 => DW1 data: Token:SETUP | EPType:CONTROL | Addr:0 | Endp:0 SetAddress(3) failed

GetDeviceDescriptor: address:3 | size:18 PTD Error: DW3: 5240_0000 => DW1 data: Token:SETUP | EPType:CONTROL | Addr:3 | Endp:0 GetDeviceDescriptor failed

The port gets powered, the hub sees a device at port 2, the port is succesfully reset and enabled, but when I issue a GetDeviceDescriptor or SetAddress, the PTD area returns (H)Halt and X(Transaction error).

What could be missing between the Clear C_PORT_RESET and GetDeviceDescriptor to get the device receiving and answering it?

I'm using an Full-Speed device.

Thanks for the help.

RTovo

Since you are using a full speed device, you using the start/complete split PTD descriptors and setting the correct parent hub address and port?

Have you you an analyser between the ISP1761 and your device?

If you are developing from scratch it is much easier to develop for a high-speed device first.

Andrew

Yea, I tried it too. Hub address is the same of the Device Address I set in the hub enumeration? Port is the number of the physical port (#2 or #3), right?

At the moment an scope.

Right, I'm testing with a HS device too. In this case the ATL PTD DONE is set for the PTD but the A (Active) field remains set.

Any other idea? Thanks for the post, Andrew.

The hub address is the nearest high-speed hub (in terms of the device topology to your device). Since you are using an ISP1761 and assuming that you are directly connecting a device to that, then it should be the address of that (not the root hub) and either port 2 or 3 depending on which port you have connected it.

Are you using your own hardware? Or are you using an evaluation board?

That's unlikely to be sufficient. Since you are developing a host you will need to see what is happening, in protocol terms, on the wire. There are a number of analysers around: LeCroy, Ellisys, Beagle at very different pricings.

I would try getting this (HS) device working first; it is more straightforward than FS. It is possible that Active is still set because the device has NAK'd several times. Have you checked the application notes/errata as there were changes to the NakCnt under some circumstances.

Andrew

Exactly, so: HubAddr = 0x0; Port = 0x2; // or 0x3 Right?

My own hardware. It is very similar to this one:

It would be very interesting, but I don't have enough time for that because I would need to import it.

Yea, I'm using this approach. First with a HS device, and once its ok, the FS device.

I've checked the AN10054_4 (FAQ). At 1.20 it says that Active bit can be de-asserted if NAK exceeds NakCnt times and then an interrupt is generated fo the software to decide whether to stop the ptd or refresh it.

Thanks, man.

Er no, the hub address should be 2 (probably) with the root hub being 1. Don't forget that 0 is the default USB address.

I almost forgot there is a complete (Linux) host driver for the ISP1761 on sourceforge. This was released by NXP last year (or possibly the year before): it may be some help to you. This has been updated a couple of times. It may give you some ideas about what to do although it isn't exactly pretty.

Andrew

Hm. Ok. Got it.

Yea, I have the v3.0.0.0. For someone who is developing a usb driver from scratch, the linux driver is VERY difficult to understand completely. I could check my initialization routine with the linux one, but the PTD management part I simply gave up understanding. My PTD management is an linear and polled way.

But the news is: Today I could get to enumerate a HS device!! The problem was: when you request an IN token to the attached device, its PTD is reported as executed by ATL DONE MAP, but the Active bit in the ptd remains set. That is very weird. So, the workaround was: when this happens, set the Valid bit again (in DW0). It worked perfectly.

Now I'm going towards FS device. Discovering why I get Halt and X. It must be some configuration on the PTD fields, like the incorrect HubAddress you pinpointed before.

Thanks again!

Hello,

Did you ever get anywhere with this?

I am having a similar problem trying to talk to a usb keyboard. The only difference is that I get a halt and no x bit. I am really at a loss.

Best Regards, Kevin Tacheny

device

assuming

the

on

2. >> Don't forget that 0 is the default USB address.

board?

ISP1761