USB Host controller - Host controller Interface to be used...

[Phani Kumar <ph...@gmail.com>]

Hi Greg and all,
Currently I am porting USB Host controller to Renesas RX65N controller and
stuck at endpoint descriptor and thought of checking with you.
Basically this endpoint descriptor - looking into lpc1740 as reference code
- struct lpc17_40_ed_s (.\arch\arm\src\lpc17xx_40xx\lpc17_40_usbhost.c)
refers to *ohci_ed_s *struct (./include/nuttx/usb/ohci.h).
As RX65N controller does not refer to any of these specs (OHCI/ UHCI/
EHCI). I think, I can also use this *ohci_ed_s* struct, as host code at OS
level may be using these specs for various USB scheduling and other things.
Please let me know if you think, usage of *ohci_ed_s* struct works for
RX65N or should I need to look into EHCI or any thing else.
With best regards,
Phani.

Non OHCI Compliant USB Host for mass storage...

[Phani Kumar <ph...@gmail.com>]

Hi Greg and all,

Currently I am working on USB Host which is plain USB host hardware (which
does not adhere to any of the spec - OHCI/ etc - provides plain registers
interfaces to manage data flow).  I have ported NuttX USB Host for Mass
storage (MSC) and it is working well for basic testing like, mount/ copy
files/ remove files etc.

As part of throughput measurement, I am trying to copy huge files with size
around 200+ KB. Some times, copy succeeds and some times code waits
indefinitely. On looking at the USB analyzer logs, I see below pattern.
1. Upper layer (usbhost_storage.c) keeps sending CBW (Command Block
Wrapper), Data (always 512 bytes) and CSW (Command Status Wrapper) in
usbhost_read()
and usbhost_write() functions.
2. When I see the issue, it is due to
a. Previous block is transmitted.
b. Upper layer (usbhost_storage.c) is trying to transfer the next block and
sends the CBW (31 bytes)
c. Device (using normal pendrive) seems to be busy (possibly it is managing
the internal details with previously received data) and there is no
response.
d. My USB Host device waits for turn around time and raises interrupt Not
Ready (NRDY).
3. With this scenario, I am trying to find out, is there any way, driver
can intimate the upper layer that device is busy/ not responding, so that
upper layer can retry sending the data? I looked at
..nuttx-8.2\include\errno.h and could not figure out which one is the
correct error to be returned for usbhost_storage.c so that re-try can
happen (EBUSY seems to be ideal, but I did not see the retry after
returning this EBUSY error).

Please let me know if you have any suggestion/ comments on handling this
kind of device behavior.

With best regards,
Phani.

>

USB Host drive porting - after enumeration....

[Phani Kumar <ph...@gmail.com>]

Hi Greg and all,

I am currently at the last stage of USB Host driver (currently using HID
KBD for test) development. If any of you have developed this kind of Host
driver/ ported - please let me know, your suggestions/ comments/
observations. It would help me a lot.

Currently I am done with the basic driver of USB Host. As soon as the
device is connected, connect event triggers and enumerates the device. This
completes getting all the details from device (mainly this is done in
usbhost_enumerate.c). I can see all the data going from device and finally
host also sets the configuration of the device. Which seems to be last
stage of the enumeration. Also if I list the folder under /dev, I see kbda
and assume enumeration is successful.
nsh> ls /dev
/dev:
console
*kbda*
null
ttyS2
ttyS8

After this, I don't see any thing from upper layer - so no activity happens
on the bus. At this point (after enumeration is done), what is the next
step? Who should start request to read the device (as the device is HID
KBD, which is already identified during enumeration).

Also I tried the Hidkbd example and I see the same behavior, as above.

Any of your comments/ suggestions/ observations on what is the next step
after enumeration - it would be really helps me a lot.

Thanks in advance and With best regards,
Phani.

>

USB Host porting - Reset before SetAddress

[Phani Kumar <ph...@gmail.com>]

Hi Greg and all,

Generally enumeration sequence of USB (from host perspective) is - start
with address 0, (i) Get the device descriptor (DD) (ii) note the control
endpoint (EP0) size of device (iii) configure the EP0 of host to EP0 of
device (iv) Get the complete 18 bytes of DD (v) Reset the device (vi) Send
setup packet on address 0 with new address (vii) Then read all the
descriptors with newly assigned address.

Currently while developing the USB host driver, I am able to get till point
(iv). This is completely done by usbhost_enumerate() function [in
usbhost_enumerate.c] - This calls first DRVR_EP0CONFIGURE() to set the
default EP0 size as 8 bytes (of host's EP0). Then gets the 8 bytes of DD
with DRVR_CTRLIN - for step (i) and (ii) above. Next  usbhost_enumerate()
calls DRVR_EP0CONFIGURE() with new size. Then gets the all the 18 bytes of
DD with DRVR_CTRLIN(). Finds out internally about new address to be
assigned and calls DRVER_CTRLOUT () to set the new address - still with
address 0.  Next DRVR_EP0CONFIGURE() is called with new address - to set
the new address in the host driver. Finally calls DRVR_CTRLIN() to get the
config descriptors with new address.

I am not very sure, if this sequence is correct. If any of you have worked
on USB Host driver, please let me know

1. My understanding is "usbhost_enumerate.c" is hardware agnostic module
and should not be modified to port USB host for different controllers. Is
this correct?

2. In the above sequece - I see missing Reset (point v as in above). It
should be supposed to be called from usbhost_enumerate() [in
usbhost_enumerate.c]. Is this my understanding correct? Or am I missing
something? Or this should be done by usb host driver itself?- so usb host
driver resets the device once it deciphers the standard set_address command?

3. Also for setting the new address (for point vi), usbhost_enumerate() [in
usbhost_enumerate.c] is calling DRVR_CTRLOUT. I think, this should be
DRVR_CTRLIN, as host issues the address as setup packet and expects 0 bytes
data as acknowledgement on control In pipe.

4. In that way, can each controller port for USB host can have its own
version of usbhost_enumerate.c?

Any of your thoughts/ comments/ suggestions would help me.

With best regards,
Phani.

How to get the rerefernce of buffer t....

[Phani Kumar <ph...@gmail.com>]

Hello Greg and others,
I am developing a USB Host controller on NuttX with hardware which is not
compliant with OHCI or EHCI. As the hardware provides setup of hardware
registers for the USB Host, I am trying to "fit" it to OHCI spec (currently
using lpc17_40_usbhost as reference).
I am confused about the usage of following buffers and how to use them in
read/ write from hardware during interrupt (in bottom half).
During initialization, EDuffer, TDBuffer, TBBuffer and xferInfo buffers are
created. I am using chunk of memory for each of these and allocated 10
buffers for each (hardware has 10 endpoints) for ED, TD, TB and xferInfo. I
assume ED for Endpoint, TD for Transfer Descriptor, TB for TransferBuffer
and xferInfo is to manage the transfer details between interrupts.
With this setup and initial configuration, I am able to detect attaching of
device and then issue first setup packet. Device sends the data and
interrupt is triggered. I ack this interrupt and start the bottom half
(worker queue) to read the data (I have the data in the hardware registers)
and in bottom half, I am not sure, where should I read this data into - ED/
TD/ TB? Also I am not sure, how to get the reference to these buffers in
bottom half?
Some pointers/ direction would help me a lot.
Thanks in advance and with best regards,
Phani.

>

Re: How (or where) does the enque function sends the data to hardware....

[Phani Kumar <ph...@gmail.com>]

Or... Do I have to *write the data to corresponding hardware registers in
the enque itself *and wait for the interrupt routine to receive the data
and release the semaphore? Basically enque of Lpc17xxx (which I am using as
reference) seems generic and not updating any hardware registers...

With best regards,
Phani.

On Tue 25 Feb, 2020, 8:35 PM Phani Kumar, <ph...@gmail.com> wrote:

> Hi Greg and all,
> I am developing the USB Host driver for RX65N, and using lpc17xxx port as
> my basic reference. Currently I can detect the device and initiate the
> standard "usbhost_enumerate()" function. This calls tballoc twice and
> prepares the buffer for (i) first setup packet request and (ii) for data to
> be received. This results in series calls to
> xxx_usbhost_ctrlin() //Think this is getting ready for reading the
> returend data from device
> -> xxx_usbhost_ctroltd () //This creates the Transfer Descriptror for the
> data transer
> -> xxx_usbhost_alloc_xfrinfo () //Prepares the data to be transmitted
> (setup packet to get teh device descriptor)
> -> and finally xxx_enquetd () //this prepares the pointers ready to be
> transmitted
> and then waits for completion on semaphore
> Some how I am not able to figure out, who/how transfer the data to actual
> hardware registers here? If the host keeps keeps pumping the data (with
> enque), where does the deque i.e. taking this out and sending out to device
> happens?
> Think I am missing very basic thing. Let me know if you have any pointers/
> suggestion for me.
> With best regards,
> Phani.
>
>>

How (or where) does the enque function sends the data to hardware....

[Phani Kumar <ph...@gmail.com>]

Hi Greg and all,
I am developing the USB Host driver for RX65N, and using lpc17xxx port as
my basic reference. Currently I can detect the device and initiate the
standard "usbhost_enumerate()" function. This calls tballoc twice and
prepares the buffer for (i) first setup packet request and (ii) for data to
be received. This results in series calls to
xxx_usbhost_ctrlin() //Think this is getting ready for reading the returend
data from device
-> xxx_usbhost_ctroltd () //This creates the Transfer Descriptror for the
data transer
-> xxx_usbhost_alloc_xfrinfo () //Prepares the data to be transmitted
(setup packet to get teh device descriptor)
-> and finally xxx_enquetd () //this prepares the pointers ready to be
transmitted
and then waits for completion on semaphore
Some how I am not able to figure out, who/how transfer the data to actual
hardware registers here? If the host keeps keeps pumping the data (with
enque), where does the deque i.e. taking this out and sending out to device
happens?
Think I am missing very basic thing. Let me know if you have any pointers/
suggestion for me.
With best regards,
Phani.

>

Porting USB Host driver on to RX65N controller...

[Phani Kumar <ph...@gmail.com>]

Hi Greg and all,
As part of porting USB Host driver for RX65N, I am referring to LPC17_40
USB Host port. Here are some of the points, where I need your suggestions.
Please let me know if you have any pointers/ other references on this.
HCCA (Host communication area details), TDTAIL (Transfer descriptor
details) and EDCTRL (Endpoint descriptor details) are referred as
respective structures. LPC17_40 has these structures located at some RAM
Area (I think, LPC17xx has dedicated memory for USB Host or something like
that) and uses this memory area for these structures (where start address
is fixed at starting point of memory, and with each size, the next
structure is referred).
In RX65N, would it be OK, to use normal memory and allocate these
structures statically - in the beginning of the file itself? Or do you
suggest to allocate memory in the init function *__usbhost_initialize ()
function and use them?
With best regards,
Phani.

>