BF533 / ISP1761 USB Host enumerating problem

Hello people.

I'm using BlackFin BF533 EZ-Kit with ISP1761 as a USB Host Controller.

I could succesfully enumerate the internal root hub thanks to the
documentation from NXP: AN10037, AN10054.
(BTW, also found out some corrections to AN10037, such as writing HC
Status Buffer Register)

Well, I can send and receive tokens to the root hub, set its address and
power the ports using the SetFeature request.

Then, my program keeps polling the hub via GetPortStatus, waiting for my
Full-Speed device to be physically connected to the port.

Once the hub detects it, I got the following:
wPortChange: 0x0001
wPortStatus:   0x0001

After that, the program issues a PORT_RESET and Gets Port Status again:
wPortChange: 0x0011   <-- Port was reset, right?
wPortStatus:   0x0001

(I also assured the port was reset by viewing the 10ms SE0 on the line)

Then, if I GetPorStatus again (one or more times), I get:
wPortChange: 0x0003
wPortStatus:   0x0001

From the USB 2.0 Spec, I understand this means port was disabled due to an
Port_Error condition.

I have been trying to solve this question for the last week: Why do I get
this Port_Error?

I wonder if any of you have already passed through this kind of problem or
have any clue about it.

(Just for testing, I try to talk to the device issuing an
GetDeviceDescriptor (at address 0), but the Setup token's PTD fields
return the 'H' and 'X' error flags.)

Thanks in advance.

On Mar 17, 4:07 pm, "Robson Tovo" <robson.t...@gmail.com> wrote:
> Hello people.
>
> I'm using BlackFin BF533 EZ-Kit with ISP1761 as a USB Host Controller.
>
> I could succesfully enumerate the internal root hub thanks to the
> documentation from NXP: AN10037, AN10054.
> (BTW, also found out some corrections to AN10037, such as writing HC
> Status Buffer Register)
>
> Well, I can send and receive tokens to the root hub, set its address and
> power the ports using the SetFeature request.
>
> Then, my program keeps polling the hub via GetPortStatus, waiting for my
> Full-Speed device to be physically connected to the port.
>
> Once the hub detects it, I got the following:
> wPortChange: 0x0001
> wPortStatus:   0x0001
>
> After that, the program issues a PORT_RESET and Gets Port Status again:
> wPortChange: 0x0011   <-- Port was reset, right?
> wPortStatus:   0x0001
>
> (I also assured the port was reset by viewing the 10ms SE0 on the line)
>
> Then, if I GetPorStatus again (one or more times), I get:
> wPortChange: 0x0003
> wPortStatus:   0x0001
>
> From the USB 2.0 Spec, I understand this means port was disabled due to an
> Port_Error condition.
>
> I have been trying to solve this question for the last week: Why do I get
> this Port_Error?
>
> I wonder if any of you have already passed through this kind of problem or
> have any clue about it.
>
> (Just for testing, I try to talk to the device issuing an
> GetDeviceDescriptor (at address 0), but the Setup token's PTD fields
> return the 'H' and 'X' error flags.)
>
> Thanks in advance.

This probably isn't the best group to be asking this on; maybe try
comp.arch.embedded or something. It does sound like you're doing
everything right. From what I understand, Port_Error events are
probably signal-integrity-related, but that's just from my reading of
the USB spec. You should see the port-enabled bit (0x02) set at the
end of the port reset, after which you can start enumeration.

My opinion: avoid USB if at all possible. The stress that I've had
over the years mucking with USB has taken untold years off of my life,
I'm sure. Writing a host driver (as you seem to be for the ISP1761,
which is I will say the nicest USB controller I've used) is about as
enjoyable as having bamboo shoots shoved under your fingernails.

Good luck.

Jason

>On Mar 17, 4:07 pm, "Robson Tovo" <robson.t...@gmail.com> wrote:
>> Hello people.
>>
>> I'm using BlackFin BF533 EZ-Kit with ISP1761 as a USB Host Controller.
>>
>> I could succesfully enumerate the internal root hub thanks to the
>> documentation from NXP: AN10037, AN10054.
>> (BTW, also found out some corrections to AN10037, such as writing HC
>> Status Buffer Register)
>>
>> Well, I can send and receive tokens to the root hub, set its address
and
>> power the ports using the SetFeature request.
>>
>> Then, my program keeps polling the hub via GetPortStatus, waiting for
my
>> Full-Speed device to be physically connected to the port.
>>
>> Once the hub detects it, I got the following:
>> wPortChange: 0x0001
>> wPortStatus:   0x0001
>>
>> After that, the program issues a PORT_RESET and Gets Port Status
again:
>> wPortChange: 0x0011   <-- Port was reset, right?
>> wPortStatus:   0x0001
>>
>> (I also assured the port was reset by viewing the 10ms SE0 on the
line)
>>
>> Then, if I GetPorStatus again (one or more times), I get:
>> wPortChange: 0x0003
>> wPortStatus:   0x0001
>>
>> From the USB 2.0 Spec, I understand this means port was disabled due to
an
>> Port_Error condition.
>>
>> I have been trying to solve this question for the last week: Why do I
get
>> this Port_Error?
>>
>> I wonder if any of you have already passed through this kind of problem
or
>> have any clue about it.
>>
>> (Just for testing, I try to talk to the device issuing an
>> GetDeviceDescriptor (at address 0), but the Setup token's PTD fields
>> return the 'H' and 'X' error flags.)
>>
>> Thanks in advance.
>
>This probably isn't the best group to be asking this on; maybe try
>comp.arch.embedded or something. 

Yea, I've already posted there too. I'm trying to get help from everywhere
I can.


>It does sound like you're doing
>everything right. From what I understand, Port_Error events are
>probably signal-integrity-related, but that's just from my reading of
>the USB spec. 

Right. Thats my reading too. But I've checked the signals in the scope and
logic analyzer.

>You should see the port-enabled bit (0x02) set at the
>end of the port reset, after which you can start enumeration.
>

Yea, I dream with the day it happens :)


>My opinion: avoid USB if at all possible. 

LOL! Thats what I told my boss.


>The stress that I've had
>over the years mucking with USB has taken untold years off of my life,
>I'm sure. Writing a host driver (as you seem to be for the ISP1761,
>which is I will say the nicest USB controller I've used) is about as
>enjoyable as having bamboo shoots shoved under your fingernails.
>

:D  Then you understand me. 
We'll become warrios of USB, those developers who died to deliver the best
experience to the home user.

>Good luck.
>
>Jason
>

Thank you a lot for the reply. 
I'll keep my journey to find the answers.

(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] <== GOOD! but...
	
	GetDeviceDescriptor: address:0 | size:8
	PTD Error: DW3: 5240_0000 => 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.