[Bug 1001024] New: STM32 USB driver and proposed USB API change

[Bug 1001024] New: STM32 USB driver and proposed USB API change

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001024

           Summary: STM32 USB driver and proposed USB API change
           Product: eCos
           Version: 3.0
          Platform: stm32e_eval (ST STM3210E EVAL board)
        OS/Version: Cortex-M
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: low
         Component: USB driver
        AssignedTo: unassigned@bugs.ecos.sourceware.org
        ReportedBy: chris@zynaptic.com
                CC: ecos-bugs@ecos.sourceware.org
             Class: Advice Request


Created an attachment (id=963)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=963)
STM32 USB slave driver package

Attached is the STM32 USB driver which has been developed and tested against
the 3.0 release.  It has had extensive testing with a proprietary USB class
driver, but there are issues with using it in conjunction with the standard
eCos class drivers which could best be fixed by an enhancement to the USB slave
API.

Instead of using static endpoint references as per existing USB slave drivers,
STM32 USB endpoints may only be accessed after USB device configuration via the
two following 'getter' functions:

// Get a handle on the specified transmit (in) endpoint.  Calling this function
// with a given logical endpoint ID will return the transmit endpoint data
// structure associated with that endpoint ID.
extern usbs_tx_endpoint* cyg_usbs_cortexm_stm32_tx_endpoint (cyg_uint32 ep_id);

// Get a handle on the specified receive (out) endpoint.  Calling this function
// with a given logical endpoint ID will return the receive endpoint data
// structure associated with that endpoint ID.
extern usbs_rx_endpoint* cyg_usbs_cortexm_stm32_rx_endpoint (cyg_uint32 ep_id);

This approach allows the STM32 USB driver to support multiple USB
configurations if required.  However, the existing standard eCos class drivers
assume the use of static endpoint definitions which will require changes to
work against this driver.

IMHO, the best way to resolve this would be to introduce a new pair of
functions to the standard USB slave API, which are generic variants of the ones
given above for the STM32.  This would be easy to add to existing drivers and
would provide a consistent way of accessing old-style fixed endpoint USB
hardware and more modern configurable USB hardware.  In addition they will hide
the native types of the endpoint data structures which currently 'leak' from
hardware specific slave drivers into class driver implementations.

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 1001024] STM32 USB driver and proposed USB API change

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001024

John Dallaway <john@dallaway.org.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ecos-patches@ecos.sourcewar
                   |                            |e.org, john@dallaway.org.uk
          Component|USB driver                  |Patches and contributions

--- Comment #1 from John Dallaway <john@dallaway.org.uk> 2010-08-26 10:13:50 BST ---
(In reply to comment #0)

Chris, thank you for the contribution. In the absence of a complete
implementation, can you clarify how you envisage the new endpoint retrieval
scheme to work please?

At present, the Rx and Tx endpoint structures to be used by a function device
package are specified using CDL options in the function device package (eg
CYGDAT_IO_USB_SLAVE_SERIAL_EP0). The relationship between endpoints and
function devices is fixed at build time.

> Instead of using static endpoint references as per existing USB slave drivers,
> STM32 USB endpoints may only be accessed after USB device configuration via
> the two following 'getter' functions:

Is specifying the endpoint structures at build time simply not possible? Or are
you proposing the new scheme to allow greater flexibility with more modern
hardware? What additional flexibility is achieved?

> // Get a handle on the specified transmit (in) endpoint.  Calling this
> // function with a given logical endpoint ID will return the transmit
> // endpoint data structure associated with that endpoint ID.
> extern usbs_tx_endpoint* cyg_usbs_cortexm_stm32_tx_endpoint
     (cyg_uint32 ep_id);
> 
> // Get a handle on the specified receive (out) endpoint.  Calling this
> // function with a given logical endpoint ID will return the receive
> // endpoint data structure associated with that endpoint ID.
> extern usbs_rx_endpoint* cyg_usbs_cortexm_stm32_rx_endpoint
     (cyg_uint32 ep_id);
> 
> This approach allows the STM32 USB driver to support multiple USB
> configurations if required.

Can you explain what you mean by "multiple configurations" here?

> However, the existing standard eCos class drivers assume the use of static
> endpoint definitions which will require changes to work against this driver.
> 
> IMHO, the best way to resolve this would be to introduce a new pair of
> functions to the standard USB slave API, which are generic variants of the
> ones given above for the STM32.  This would be easy to add to existing
> drivers and would provide a consistent way of accessing old-style fixed
> endpoint USB hardware and more modern configurable USB hardware.  In addition
> they will hide the native types of the endpoint data structures which
> currently 'leak' from hardware specific slave drivers into class driver
> implementations.

If we provide the following functions in the generic USB slave API:

  usbs_rx_endpoint* cyg_usbs_rx_endpoint (cyg_uint32 ep_id);
  usbs_rx_endpoint* cyg_usbs_tx_endpoint (cyg_uint32 ep_id);

how do you propose that the implementation of these functions looks up the
endpoint structure? Another parameter to specify the hardware device driver
lookup function?

How would the user of the USB function driver continue to specify the endpoints
using CDL options?

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 1001024] STM32 USB driver and proposed USB API change

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001024

--- Comment #2 from Chris Holgate <chris@zynaptic.com> 2010-08-26 12:00:12 BST ---
(In reply to comment #1)

> At present, the Rx and Tx endpoint structures to be used by a function device
> package are specified using CDL options in the function device package (eg
> CYGDAT_IO_USB_SLAVE_SERIAL_EP0). The relationship between endpoints and
> function devices is fixed at build time.

This is fine for the older hardware which has limited configurability, but
doesn't scale well for newer, more flexible hardware (see below).

> Is specifying the endpoint structures at build time simply not possible? Or are
> you proposing the new scheme to allow greater flexibility with more modern
> hardware? What additional flexibility is achieved?

Consider that the STM32 has 7 fully configurable data endpoints - each of which
may be configured as an input or an output, each of which may be bulk,
interrupt or isochronous, each of which may be configured with arbitrary packet
sizes and each of which may be assigned an arbitrary logical endpoint number. 
Configuring that in the same way as existing drivers would be a CDL and #ifdef
nightmare.  

Fortunately, for any given class driver the definitive settings for all these
configuration options is present in the form of the class driver descriptors. 
By parsing the class driver descriptors for this information, the STM32 driver
avoids the user having to duplicate all the class driver descriptor settings as
CDL options.

> > This approach allows the STM32 USB driver to support multiple USB
> > configurations if required.
> 
> Can you explain what you mean by "multiple configurations" here?

USB device configurations are part of the USB spec that allows the host to set
up a device to behave as a specific class.  An example would be a camera which
supports a standard mass storage configuration as well as a PTP configuration. 
Each configuration will correspond to a different interface and endpoint setup
on the USB device.  The host notifies the device of the configuration it wants
to use during device bringup and the device must reconfigure its endpoint
settings as required by the selected configuration.

> If we provide the following functions in the generic USB slave API:
> 
>   usbs_rx_endpoint* cyg_usbs_rx_endpoint (cyg_uint32 ep_id);
>   usbs_rx_endpoint* cyg_usbs_tx_endpoint (cyg_uint32 ep_id);
> 
> how do you propose that the implementation of these functions looks up the
> endpoint structure? Another parameter to specify the hardware device driver
> lookup function?

The functions would need to be indirected through the control endpoint data
structure as per the existing USB API functions.

> How would the user of the USB function driver continue to specify the endpoints
> using CDL options?

Existing USB slave drivers can still export their static endpoint data
structures as before.  Existing class drivers which rely on this configuration
approach will continue to work with the existing USB slave drivers, but will
need to be reworked if they are to be used with the new API functions.

To work with the new API, existing USB slave drivers will need to add the
endpoint 'getter' functions and extra CDL configuration options which allow the
logical endpoint IDs requested via these functions to be mapped to the
appropriate physical endpoint data structures.

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 1001024] STM32 USB driver and proposed USB API change

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001024

--- Comment #3 from John Dallaway <john@dallaway.org.uk> 2010-09-03 15:00:08 BST ---
(In reply to comment #2)

> > If we provide the following functions in the generic USB slave API:
> > 
> >   usbs_rx_endpoint* cyg_usbs_rx_endpoint (cyg_uint32 ep_id);
> >   usbs_rx_endpoint* cyg_usbs_tx_endpoint (cyg_uint32 ep_id);
> > 
> > how do you propose that the implementation of these functions looks up the
> > endpoint structure? Another parameter to specify the hardware device driver
> > lookup function?
> 
> The functions would need to be indirected through the control endpoint data
> structure as per the existing USB API functions.

Chris, can you provide an example implementation of this in the form of a patch
for the USB slave I/O layer and the USB serial function device? With a complete
implementation in place, it should be clear to everyone how to roll out the
improved API to other drivers over time.

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 1001024] STM32 USB driver and proposed USB API change

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001024

--- Comment #4 from Chris Holgate <chris@zynaptic.com> 2010-09-13 20:30:48 BST ---
Created an attachment (id=975)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=975)
Modified USB slave API - for comment only.

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 1001024] STM32 USB driver and proposed USB API change

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001024

Chris Holgate <chris@zynaptic.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #963 is|0                           |1
           obsolete|                            |

--- Comment #5 from Chris Holgate <chris@zynaptic.com> 2010-09-13 20:31:58 BST ---
Created an attachment (id=976)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=976)
STM32 USB driver package using proposed API changes - for comment only.

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 1001024] STM32 USB driver and proposed USB API change

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001024

--- Comment #6 from Chris Holgate <chris@zynaptic.com> 2010-09-13 20:50:53 BST ---
Hi John,

(In reply to comment #3)
> Chris, can you provide an example implementation of this in the form of a patch
> for the USB slave I/O layer and the USB serial function device? With a complete
> implementation in place, it should be clear to everyone how to roll out the
> improved API to other drivers over time.

I've included a proposed patch which adds the extra functionality to the USB
slave API, together with a modified version of the STM32 driver which makes use
of the additional API functionality.  These are for comment only, as they seem
to be OK but have not yet had a proper workout.

I've got a pretty demanding contract on at the moment, but I'll try and get
some proper testing in when I have the time and will report back when I'm happy
with the changes.  However, this will probably be with my proprietary class
driver rather than one of the standard eCos ones.  A patch against the standard
eCos serial driver will take a little longer.

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 1001024] STM32 USB driver and proposed USB API change

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001024

John Dallaway <john@dallaway.org.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fpagliughi@mindspring.com

--- Comment #7 from John Dallaway <john@dallaway.org.uk> 2010-09-17 14:11:01 BST ---
Chris, thank you for the attachments. I've been experimenting with them and
have reached the point where my linux box is recognising the connection of a
serial device:

Sep 17 13:38:35 cog kernel: usb 4-1: new full speed USB device using uhci_hcd
and address 20
Sep 17 13:38:35 cog kernel: usb 4-1: device descriptor read/all, error -71
Sep 17 13:38:35 cog kernel: usb 4-1: new full speed USB device using uhci_hcd
and address 21
Sep 17 13:38:35 cog kernel: usb 4-1: device descriptor read/all, error -71
Sep 17 13:38:35 cog kernel: usb 4-1: new full speed USB device using uhci_hcd
and address 22
Sep 17 13:38:35 cog kernel: usb 4-1: device descriptor read/8, error -71
Sep 17 13:38:35 cog kernel: usb 4-1: configuration #1 chosen from 1 choice

Meanwhile, the STM32 USB driver reports:

### 3:Powered ###
### 4:Reset ###
### 4:Reset ###
### 4:Reset ###
### 4:Reset ###
STM32 USB : Setting USB device address = 20
### 5:Addressed ###
### 4:Reset ###
### 4:Reset ###
STM32 USB : Setting USB device address = 21
### 5:Addressed ###
### 4:Reset ###
STM32 USB : Setting USB device address = 22
### 5:Addressed ###
STM32 USB : Setting USB configuration = 1
### 6:Configured ###

To get this far, I have:

a) set CYGDAT_IO_USB_SLAVE_SERIAL_EP0 == "cyg_usbs_cortexm_stm32_ep0c"
b) commented out references to the static rx/tx/intr endpoint structs in
   usbs_serial.c, and
c) modified the parameters passed into usbs_serial_init():

  void
  usbs_serial_start(void)
  {
    usbs_serial_init(&usbs_ser0,
      usbs_get_tx_endpoint(usbs_serial_ep0, TX_EP_NUM),
      usbs_get_rx_endpoint(usbs_serial_ep0, RX_EP_NUM));
        ......

lsusb reports:

Bus 004 Device 022: ID ffff:0001  
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0        64
  idVendor           0xffff 
  idProduct          0x0001 
  bcdDevice            0.00
  iManufacturer           1 eCos
  iProduct                2 eCos USB Serial Device
  iSerial                 0 
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           32
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0xc0
      Self Powered
    MaxPower              100mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass      0 
      bInterfaceProtocol      0 
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x02  EP 2 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0

"Vendor Specific Class" doesn't look good. Are there any clues here as to the
problem? I am adding Frank Pagliughi (eCos USB slave serial author) to the CC
list in case he has some insights on how to debug this.

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 1001024] STM32 USB driver and proposed USB API change

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001024

--- Comment #8 from Chris Holgate <chris@zynaptic.com> 2010-09-17 19:02:53 BST ---
Hi John,

(In reply to comment #7)
> Chris, thank you for the attachments. I've been experimenting with them and
> have reached the point where my linux box is recognising the connection of a
> serial device:
> 
> "Vendor Specific Class" doesn't look good. Are there any clues here as to the
> problem? I am adding Frank Pagliughi (eCos USB slave serial author) to the CC
> list in case he has some insights on how to debug this.

Looking at the reported endpoints, I'm guessing that you need to set
CYGDAT_IO_USB_SLAVE_CLASS_TYPE to ACM to get the standard serial class driver
setup.  The generic option appears to set the class field to 'vendor specific'
- presumably because omitting the interrupt endpoint renders it non-compliant
with the spec.

I suspect that there are plenty of 'vendor specific' USB products out there
which are really just serial ports under the hood, and where the vendor drivers
are only there to map them to a generic COM/TTY port.

Chris.

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 1001024] STM32 USB driver and proposed USB API change

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001024

--- Comment #9 from John Dallaway <john@dallaway.org.uk> 2010-10-07 11:12:59 BST ---
Chris, with CYGDAT_IO_USB_SLAVE_CLASS_TYPE == "ACM", lsusb looks better (but
scroll down for the problem):

Bus 004 Device 008: ID ffff:0001  
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            2 Communications
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0         8
  idVendor           0xffff 
  idProduct          0x0001 
  bcdDevice            0.00
  iManufacturer           1 eCos
  iProduct                2 eCos USB Serial Device
  iSerial                 0 
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           48
    bNumInterfaces          2
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0xc0
      Self Powered
    MaxPower              100mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         2 Communications
      bInterfaceSubClass      2 Abstract (modem)
      bInterfaceProtocol      1 AT-commands (v.25ter)
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x83  EP 3 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval             255
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        1
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass        10 CDC Data
      bInterfaceSubClass      0 Unused
      bInterfaceProtocol      0 
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x02  EP 2 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0

usb_start() and usbs_serial_wait_until_configured() are required before calling
usbs_get_[rt]x_endpoint() so the sequence of calls in usbs_serial_start()
needed re-ordering. I'm now getting an assertion failure due to invalid
endpoint in stm32_usb_get_txep() and it looks like the TX endpoint map is not
correct:

(gdb) print txep_map
$8 = {0x0, 0x0, 0x68024ae0, 0x0 <repeats 12 times>}

stm32_usb_get_txep() is looking up logical endpoint 1 (TX) and therefore
retrieving element 0 which is 0x0. Any ideas?

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 1001024] STM32 USB driver and proposed USB API change

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001024

--- Comment #10 from Chris Holgate <chris@zynaptic.com> 2010-10-07 20:23:13 BST ---
Hi John,

(In reply to comment #9)
> Chris, with CYGDAT_IO_USB_SLAVE_CLASS_TYPE == "ACM", lsusb looks better (but
> scroll down for the problem):
> 
> Bus 004 Device 008: ID ffff:0001  
> Device Descriptor:
>   bLength                18
>   bDescriptorType         1
>   bcdUSB               2.00
>   bDeviceClass            2 Communications
>   bDeviceSubClass         0 
>   bDeviceProtocol         0 
>   bMaxPacketSize0         8
>   idVendor           0xffff 
>   idProduct          0x0001 
>   bcdDevice            0.00
>   iManufacturer           1 eCos
>   iProduct                2 eCos USB Serial Device
>   iSerial                 0 
>   bNumConfigurations      1
>   Configuration Descriptor:
>     bLength                 9
>     bDescriptorType         2
>     wTotalLength           48
>     bNumInterfaces          2
      ^^^^^^^^^^^^^^^^^^^^^^^^^

I think this is the problem, since the driver has not previously been tested
with multiple interface declarations.  Looks like there is a possible bug in
the driver which doesn't deal properly with this situation when setting up the
endpoints.  I should have some time this weekend to sort out a fix.

Chris.

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 1001024] STM32 USB driver and proposed USB API change

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001024

Chris Holgate <chris@zynaptic.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #976 is|0                           |1
           obsolete|                            |

--- Comment #11 from Chris Holgate <chris@zynaptic.com> 2010-10-09 15:38:07 BST ---
Created an attachment (id=994)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=994)
STM32 USB driver package fixing multiple interface bug - to be tested.

This updated version of the STM32 USB driver package should fix the bug which
John encountered with the multiple interface configuration used by the serial
driver.  There are no regressions against the single interface setup that I am
using, but I have not had chance to test it against the serial driver package
yet.  Debug tracing is now selectable via a CDL option and will now report the
endpoints in use as they are set up.

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 1001024] STM32 USB driver and proposed USB API change

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001024

John Dallaway <john@dallaway.org.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned@bugs.ecos.source |john@dallaway.org.uk
                   |ware.org                    |

--- Comment #12 from John Dallaway <john@dallaway.org.uk> 2010-10-15 14:51:27 BST ---
Chris, thank you for the updated driver. The cdc-acm driver on my Linux box is
now reporting "Zero length descriptor references":

Oct 15 13:11:27 cog kernel: usb 4-1: new full speed USB device using uhci_hcd
and address 28
Oct 15 13:11:37 cog kernel: usb 4-1: configuration #1 chosen from 1 choice
Oct 15 13:11:37 cog kernel: drivers/usb/class/cdc-acm.c: Zero length descriptor
references
Oct 15 13:11:37 cog kernel: 
Oct 15 13:11:37 cog kernel: cdc_acm: probe of 4-1:1.0 failed with error -22

This seems to be widely reported on the net with random ACM hardware so I have
switched back to CYGDAT_IO_USB_SLAVE_CLASS_TYPE == "generic" for the time
being.

With the eCos "generic" USB serial support, I'm issuing:

  modprobe usbserial vendor=0xffff product=0x0001

and seeing:

Oct 15 13:49:49 cog kernel: usb 4-1: new full speed USB device using uhci_hcd
and address 35
Oct 15 13:49:59 cog kernel: usb 4-1: configuration #1 chosen from 1 choice
Oct 15 13:49:59 cog kernel: usbserial_generic 4-1:1.0: generic converter
detected
Oct 15 13:49:59 cog kernel: usb 4-1: generic converter now attached to ttyUSB0

So far, so good.

I can connect to /dev/ttyUSB0 using minicom and send/receive chars over USB.

The remaining problem is that every other char I receive on the eCos side is a
copy of the previous character received. If I type "abcdefgh" into minicom,
eCos receives "?bbddffh". The very first char received is random. The timing of
all received characters is as expected (immediately after hitting the key). The
transmission of chars from eCos to minicom is working correctly.

Can you see how this issue might arise with your latest STM32 USB driver code?
Is there some further tracing I could add to debug this?

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 1001024] New: STM32 USB driver and proposed USB API change

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001024

           Summary: STM32 USB driver and proposed USB API change
           Product: eCos
           Version: 3.0
          Platform: stm32e_eval (ST STM3210E EVAL board)
        OS/Version: Cortex-M
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: low
         Component: USB driver
        AssignedTo: unassigned@bugs.ecos.sourceware.org
        ReportedBy: chris@zynaptic.com
                CC: ecos-bugs@ecos.sourceware.org
             Class: Advice Request


Created an attachment (id=963)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=963)
STM32 USB slave driver package

Attached is the STM32 USB driver which has been developed and tested against
the 3.0 release.  It has had extensive testing with a proprietary USB class
driver, but there are issues with using it in conjunction with the standard
eCos class drivers which could best be fixed by an enhancement to the USB slave
API.

Instead of using static endpoint references as per existing USB slave drivers,
STM32 USB endpoints may only be accessed after USB device configuration via the
two following 'getter' functions:

// Get a handle on the specified transmit (in) endpoint.  Calling this function
// with a given logical endpoint ID will return the transmit endpoint data
// structure associated with that endpoint ID.
extern usbs_tx_endpoint* cyg_usbs_cortexm_stm32_tx_endpoint (cyg_uint32 ep_id);

// Get a handle on the specified receive (out) endpoint.  Calling this function
// with a given logical endpoint ID will return the receive endpoint data
// structure associated with that endpoint ID.
extern usbs_rx_endpoint* cyg_usbs_cortexm_stm32_rx_endpoint (cyg_uint32 ep_id);

This approach allows the STM32 USB driver to support multiple USB
configurations if required.  However, the existing standard eCos class drivers
assume the use of static endpoint definitions which will require changes to
work against this driver.

IMHO, the best way to resolve this would be to introduce a new pair of
functions to the standard USB slave API, which are generic variants of the ones
given above for the STM32.  This would be easy to add to existing drivers and
would provide a consistent way of accessing old-style fixed endpoint USB
hardware and more modern configurable USB hardware.  In addition they will hide
the native types of the endpoint data structures which currently 'leak' from
hardware specific slave drivers into class driver implementations.

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.