[Bug 1001084] New: STM32 USB driver unplugging/replugging issue

[Bug 1001084] New: STM32 USB driver unplugging/replugging issue

[bugzilla-daemon]

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

           Summary: STM32 USB driver unplugging/replugging issue
           Product: eCos
           Version: CVS
          Platform: stm32e_eval (ST STM3210E EVAL board)
        OS/Version: Cortex-M
            Status: NEW
          Severity: normal
          Priority: normal
         Component: USB driver
        AssignedTo: unassigned@bugs.ecos.sourceware.org
        ReportedBy: john@dallaway.org.uk
                CC: ecos-bugs@ecos.sourceware.org, chris@zynaptic.com,
                    ilijas@siva.com.mk
             Class: Advice Request


There appears to be a problem with configuration of the STM32 USB driver
following unplugging and reconnection of the USB cable. This is observed with
both the USB mass storage and USB serial tests against a Linux host (CentOS 5).
For example, with the USB mass storage test (usbs_test_ramdisk):

a) run the test
b) mount the disk on a remote machine
c) check reading/writing of files on the FAT12 partition OK
d) unmount
e) unplug USB cable
f) reconnect USB cable
g) observe STM32 USB driver does not reach the configured state

Note that both the USB serial tests and the USB mass storage handler
usbs_msd_handler() are designed to loop and wait for a new connection by
calling usbs_*_wait_until_configured() following disconnection.

Has anyone else observed this issue?

-- 
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 1001084] STM32 USB driver unplugging/replugging issue

[bugzilla-daemon]

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

--- Comment #1 from Chris Holgate <chris@zynaptic.com> 2010-11-30 20:45:02 GMT ---
Hi John,

I'm guessing that you have the STM32 board powered up throughout this test.  If
so, unmounting the file system will not be sufficient - the host will not
perform the required control endpoint actions to take the device out of the
configured state ready for clean removal.  I think that 'eject' should do this
correctly.

To be honest, USB device testing is one place where you're better of using
Windows...

-- 
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 1001084] STM32 USB driver unplugging/replugging issue

[bugzilla-daemon]

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

--- Comment #3 from Chris Holgate <chris@zynaptic.com> 2010-12-01 20:51:03 GMT ---
Having given it a bit more thought, I don't think that this is a scenario that
the USB protocol can be guaranteed to handle cleanly - there is too much
low-level bus state involved.  I think the safest approach is to detect
disconnection from the host by monitoring the USB bus power line and using this
as a trigger to restart the USB interface ready for a clean connection to the
new host.

-- 
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 1001084] STM32 USB driver unplugging/replugging issue

[bugzilla-daemon]

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

--- Comment #2 from John Dallaway <john@dallaway.org.uk> 2010-12-01 11:04:47 GMT ---
Chris, thank you for your comment.

(In reply to comment #1)

> I'm guessing that you have the STM32 board powered up throughout this test.

Correct.

> If so, unmounting the file system will not be sufficient - the host will not
> perform the required control endpoint actions to take the device out of the
> configured state ready for clean removal.  I think that 'eject' should do this
> correctly.
> 
> To be honest, USB device testing is one place where you're better of using
> Windows...

I will experiment on Windows. If the scenario I outline in this report works
correctly on Windows, we will have a better understanding of the issue.
Clearly, it is important that eCos applications can recover from _unexpected_
USB disconnections.

-- 
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 1001084] New: STM32 USB driver unplugging/replugging issue

[bugzilla-daemon]

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

           Summary: STM32 USB driver unplugging/replugging issue
           Product: eCos
           Version: CVS
          Platform: stm32e_eval (ST STM3210E EVAL board)
        OS/Version: Cortex-M
            Status: NEW
          Severity: normal
          Priority: normal
         Component: USB driver
        AssignedTo: unassigned@bugs.ecos.sourceware.org
        ReportedBy: john@dallaway.org.uk
                CC: ecos-bugs@ecos.sourceware.org, chris@zynaptic.com,
                    ilijas@siva.com.mk
             Class: Advice Request


There appears to be a problem with configuration of the STM32 USB driver
following unplugging and reconnection of the USB cable. This is observed with
both the USB mass storage and USB serial tests against a Linux host (CentOS 5).
For example, with the USB mass storage test (usbs_test_ramdisk):

a) run the test
b) mount the disk on a remote machine
c) check reading/writing of files on the FAT12 partition OK
d) unmount
e) unplug USB cable
f) reconnect USB cable
g) observe STM32 USB driver does not reach the configured state

Note that both the USB serial tests and the USB mass storage handler
usbs_msd_handler() are designed to loop and wait for a new connection by
calling usbs_*_wait_until_configured() following disconnection.

Has anyone else observed this issue?

-- 
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.

[Bug 1001084] STM32 USB driver unplugging/replugging issue

[bugzilla-daemon]

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

--- Comment #1 from Chris Holgate <chris@zynaptic.com> 2010-11-30 20:45:02 GMT ---
Hi John,

I'm guessing that you have the STM32 board powered up throughout this test.  If
so, unmounting the file system will not be sufficient - the host will not
perform the required control endpoint actions to take the device out of the
configured state ready for clean removal.  I think that 'eject' should do this
correctly.

To be honest, USB device testing is one place where you're better of using
Windows...

-- 
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.

[Bug 1001084] STM32 USB driver unplugging/replugging issue

[bugzilla-daemon]

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

--- Comment #2 from John Dallaway <john@dallaway.org.uk> 2010-12-01 11:04:47 GMT ---
Chris, thank you for your comment.

(In reply to comment #1)

> I'm guessing that you have the STM32 board powered up throughout this test.

Correct.

> If so, unmounting the file system will not be sufficient - the host will not
> perform the required control endpoint actions to take the device out of the
> configured state ready for clean removal.  I think that 'eject' should do this
> correctly.
> 
> To be honest, USB device testing is one place where you're better of using
> Windows...

I will experiment on Windows. If the scenario I outline in this report works
correctly on Windows, we will have a better understanding of the issue.
Clearly, it is important that eCos applications can recover from _unexpected_
USB disconnections.

-- 
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.

[Bug 1001084] STM32 USB driver unplugging/replugging issue

[bugzilla-daemon]

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

--- Comment #3 from Chris Holgate <chris@zynaptic.com> 2010-12-01 20:51:03 GMT ---
Having given it a bit more thought, I don't think that this is a scenario that
the USB protocol can be guaranteed to handle cleanly - there is too much
low-level bus state involved.  I think the safest approach is to detect
disconnection from the host by monitoring the USB bus power line and using this
as a trigger to restart the USB interface ready for a clean connection to the
new host.

-- 
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.