Re: BF533 / ISP1761 USB Host enumerating problem
- From: "Robson Tovo" <robson.tovo@xxxxxxxxx>
- Date: Tue, 18 Mar 2008 20:08:45 -0500
On Mar 17, 4:07 pm, "Robson Tovo" <robson.t...@xxxxxxxxx> wrote:and
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
mypower the ports using the SetFeature request.
Then, my program keeps polling the hub via GetPortStatus, waiting for
again: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
line)wPortChange: 0x0011 <-- Port was reset, right?
wPortStatus: 0x0001
(I also assured the port was reset by viewing the 10ms SE0 on the
an
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
getPort_Error condition.
I have been trying to solve this question for the last week: Why do I
orthis Port_Error?
I wonder if any of you have already passed through this kind of problem
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.
.
- Follow-Ups:
- Re: BF533 / ISP1761 USB Host enumerating problem
- From: Robson Tovo
- Re: BF533 / ISP1761 USB Host enumerating problem
- References:
- BF533 / ISP1761 USB Host enumerating problem
- From: Robson Tovo
- Re: BF533 / ISP1761 USB Host enumerating problem
- From: cincydsp
- BF533 / ISP1761 USB Host enumerating problem
- Prev by Date: Re: Bandpass system identification using IIRs (audio)
- Next by Date: Re: Opinions on "Multirate Signal Processing..." by F.J.Harris?
- Previous by thread: Re: BF533 / ISP1761 USB Host enumerating problem
- Next by thread: Re: BF533 / ISP1761 USB Host enumerating problem
- Index(es):
Relevant Pages
|