i.MX ProcessorsのトピックRe: USB Attach Failure i.MX28 Windows CE 6.0 Memory Stick

USB Attach Failure i.MX28 Windows CE 6.0 Memory Stick

markwilliams — Wed, 24 Feb 2016 14:38:22 GMT

Hi all,

We have been battling issues with USB memory stick support for some time with the i.MX28 Windows CE BSP. We have implemented a number of 'fixes' ranging from Microsoft updates, Errata Work-arounds and general Windows CE fixes from other BSPs or user experiences found online and in these forums.

We have an issue where after several insertions of a memory stick the USB port appears to lock up and on the next device attachment the 'AttachDevice' process fails at DEVICE_CONFIG_STATUS_SCHEDULING_GET_DEVICE_DESCRIPTOR_TEST. This is actually the first point in the attach process that an attempt is made to communicate with the device and uses ENPOINT 0 on a control pipe created during earlier stages of the AttachProcess.

Once the port has failed it no longer responds to any other USB device and fails at this same point every time. The pipe has the halt flag set and is non-functional. The only way to recover seems to be to power cycle the unit.

We have found forum posts that recommend increasing the delay from ResetAndEnablePort (the previous step) and sending any data. By default in the BSP this is 10ms but some devices may not be ready to communicate at this point and still coming out of reset. We have tried increasing to 100ms and the results initially seemed promising but we could eventually get it to fail again after repeated insertions.

We have used a USB logger to see what happens on the bus through several insertions to failure. For each successful attach and detach we see no bus errors and can decode the SCSI packets. The last successful transfer on removal was the last SCSI Test Unit Ready packet which is sent to poll for disk removal.

When we insert the disk and there is a failure we just see babbled data out of the USB port. There isn't a single valid packet but random data bytes being received by the analyser following device reset. The analyser cannot tell if the memory stick is babbling or the i.MX28 processor as it is just receiving random bytes constantly.

I have attached the last successful transfer below (note that NAKs and SOF are hidden). The memory stick was unplugged in the middle of this screenshot which is why the analyser detected suspend (no bus activity). The Reset following the suspend is when the stick was re-inserted. You can see that following this we just have babbled data. The bytes are random values.

On a successful remove / attach we see that after the suspend there are two resets and we have the initial 'get descriptor test' followed by the address set and the rest of the successful enumeration.

I have been adding debug messages at various points to try and figure out what could be going on. I am not sure why the USB port has the random data on it. Perhaps there is a corrupt qHead/qTD that is just running through memory sending out random data bytes but the data is not in any of the proper transfer types (SETUP/IN/OUT).

The transfer queue should be torn down on removal and cleared out and then recreated on the first transfer on attach.

Has anyone seen anything similar or could offer some debugging advice?

Thank you in advance, Mark

Re: USB Attach Failure i.MX28 Windows CE 6.0 Memory Stick

markwilliams — Wed, 24 Feb 2016 14:42:12 GMT

Some more examples of the random data on the port on failure. Note if we disconnect and reconnect this still persists.

Re: USB Attach Failure i.MX28 Windows CE 6.0 Memory Stick

Yuri — Thu, 25 Feb 2016 04:21:57 GMT

Hello,

Please look at my comments below.

As first step, please try to test DRAM memory.

You may use the memory test, provided in Community.

"i.MX28 DDR stress test"

< https://community.freescale.com/message/375263#375263 >

Below is possible new i.MX28 erratum.ERR006308: USB: HOST controller lock-up issue.

Description:

The USB host controller can lock-up when a FIFO under run occurs on a non-32-bit aligned

data buffer. This applies to both the Host controller and OTG controller in host mode.

Workaround:

2.1. Set Stream Disable bit (SDIS) in the USBMODE register. This will force the controller to

load an entire packet in the FIFO before starting to transmit on the USB bus. Hence, the

FIFO will never underrun. This will somewhat reduce the max bandwidth of the USB since

there will be idle time as the the controller waits for the entire packet to be loaded.

2.2. Instead of setting SDIS, the FIFO threshold can be increased such that more data will be

in the FIFO before a packet transmit is started. This increases the tolerance to bus latency

and avoid FIFO under run. The Threshold can be increased by using higher values for the

TXTHRESHOLD filed in the TXFILLTUNING register. The default value is 2 bursts (64 bytes

if burst size=8).

You may try to decrease USB speed (full-speed) as described in

< https://community.freescale.com/thread/307678 >

If this helps, the issue may be caused by hardware problems, in particular as following.

USB functionality is critical regarding clock accuracy, please try to exchange

24 MHz oscillator.

Have a great day,
Yuri

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

Re: USB Attach Failure i.MX28 Windows CE 6.0 Memory Stick

Radist — Thu, 25 Feb 2016 08:00:01 GMT

Hi Mark,

I have some experience with iMX28 and USB and i also had an issues with USB stick at iMX28

please answer on next questions:

1) How many different kind of sticks have you tried to connect to the board? By USB standard, USB memory stick should have crystal with frequency stability better than 50ppm. Some time ago we found, that very cheap USB sticks without crystal (only with RC) works very unstable.

2) Is it custom board with iMX28? Do you have screenshot of USB traces from MCU to USB port? USB should be routed according to the standard, otherwise you will see some strange issues, that you will never fix with SW.

3) How many PCBs have you made and how many has this issue? At some of our devices, that now at mass production, we found that BGA and crystal was mounted not so good, and it was additional capacitance between iMX28 package and PCB. As a result - frequency deviation from 24MHz was more than 150ppm. I recommend you to check, that you have frequency at crystal inside the range 24MHz +/-50ppm (you can do that with spectrum analyzer or with pulse counter. Oscilloscope usually will not have needed accuracy).

4) Can you provide SCH for USB host port?

Regards,

Sergii

Re: USB Attach Failure i.MX28 Windows CE 6.0 Memory Stick

markwilliams — Thu, 25 Feb 2016 09:00:56 GMT

Sergii,

Thanks for your reply and the pointers above. Its worth mentioning that all of these tests are carried out limited to full speed.

A long time ago when I first started working with the iMX28 (2012) I had issues with high speed USB on memory sticks despite signal integrity measurements showing great signal quality. I have since applied numerous microsoft driver fixes around the SCSI transfers but the one that made high speed reliable (at the time) was the iMX28 errata that recommends the arm swap instruction for register writes. That being said as I was unable to perform enough testing I carried on with the port limited to full speed.

Also the issue only occurs on some memory sticks during attach and that is only on a few. The first transfer fails and the controller is babbling data out of the USB port so I am inclined to think that there is something in the way the transfer descriptors are set up that is causing corruption and the controller to output random data. Previous insertions and data transfers do not have a single error. But of course I am open to look at any suggestions.

With regards to the trace routing this has been carefully done with controlled impedance lines, length matched from processor to connector in less than 50mm and in accordance with a few different USB guideline documents. There is a USB ESD diode (low enough capacitance for USB high speed) but we already tried removing that in very early tests just in case. Anyway at full-speed limited USB the signal integrity issues are really unlikely to play a part.

Even with the port set to high speed I have performed USB signal integrity tests with a low capacitance differential probe using the USB test patters. The eye is nice open and clean.

I have also run multiple USB attach and transfer tests with a protocol analyser without any error conditions across the bus on successful attach. So this seems to be something relating to the driver being left in a bad state from the last detach, or not being configured correctly on the next attach. There are a couple of chip errata around this.

We have shipped over 5000 boards using this processor and memory layout. There are two boards with different USB routings - one with a 3-port hub and the other with a single direct host port.

I have bought 20 different memory sticks ranging from no-brand vendors up to expensive branded parts with various capacities. Some memory sticks can produce this quicker than others.

Another thought is that the 10ms following port ResetAndEnable might not be enough and the subsequent first endpoint 0 transfer may fail as the device is not ready. If there is not a mechanism to handle this first transfer failing then it could be an issue. There certainly was no mechanism to retry from a control pipe failure until I found some additional code that was added to the iMX27 BSP and ported it across to the iMX28. All this did was allow three attempts at the control transfer but still continuously failed from that point.

Thank you for the oscillator pointers. I will have to check this spec again (I chose the crystal four years ago) but I recall it being a low PPM part with high speed USB reliability in mind.

Mark

Re: USB Attach Failure i.MX28 Windows CE 6.0 Memory Stick

markwilliams — Thu, 25 Feb 2016 09:10:20 GMT

Yuri,

Thank you for your reply above. I have replied with some more detail to Sergii below. The post regarding limiting the port to full speed was mine from quite a few years ago! These issues are happening on attach for a small number of devices on random insertions limited to full speed. If the disk does mount then USB transfers are reliable and I do not see errors on my protocol analyser. If there was an underlying clock or signal integrity issue (even at full speed) then I would expect to see errors in other places and not just a failed attach.

Also once in this state the port is just sending out random data so it does seem to look like something has happened to the controller or its transfer queue pointers to make it babble. I am open to all suggestions though.

With regards to the DDR stress test, this is something that I would like to do independent of the USB issues anyway. I would need to rebuild for my DDR capacity and timings as I am not using the same part as the reference design. I will have a read of the posts - hopefully they explain how to go about rebuilding the test.

With regards to the errata this must be a hidden NXP internal errata! The current errata document for customers is V2 from 2012 and doesn't mention this. Is there somewhere else I need to look for errata for the iMX28 in case I am missing anything else?

I have heard the same USB controller (Chipidea?) is used on other processors but I am not sure if the same errata applies across the iMX range.

I will have a read and test the errata fix suggestion.

Thanks, Mark

Re: USB Attach Failure i.MX28 Windows CE 6.0 Memory Stick

Radist — Thu, 25 Feb 2016 09:27:14 GMT

Hi Mark,

i can see you made deep research there.

I am not expert in USB from SW point of view, so can't say nothing about ResetAndEnable issue.

Regarding crystal - we also had 20ppm crystal, but due to bad mounting and some issues, frequency at the crystal was 24MHz + 150ppm.

Try to heat your MCU with air solder station (to have +70....+80C at MCU) and check will you have this issue, and repeat test with some freeze cooling spray. It could be interesting to see results.

Also, if you have an issue only after inserting, - what is going on with VBUS power at this moment? Please check that you have stable +5V without any drops and peaks just after insertion. Maybe you have big capacitor at the USB port and it need more than 10ms for charging? So, in that case you will have stable +5V just after plug in.

As i understand you have USB port power switch and you are controlling it from MCU? Can you try to apply +5V directly to USB host port without any switchers?

Sergii

Re: USB Attach Failure i.MX28 Windows CE 6.0 Memory Stick

markwilliams — Thu, 25 Feb 2016 11:53:24 GMT

Hi Sergii,

Thanks for the advice on the crystal.

With regards to power dips we have analysed this. We have a single USB current limited switch (500mA) on the port and the recommended 150uF capacitance to minimise droops on the host PSU when a device is plugged in and needs to charge its internal capacitance.

The 5V supply holds up well - there is brief ns of glitch on the 5V rail at the connector as the device is connected but not on the system 5V rail - this is likely due to the power supply ferrite beads and inability to respond to the instantaneous current required when plugging in a new device. The 5V rail as the device sees it just comes up quickly on attach as expected on a hot plug. There is no after-effect for example a trigger of the power switch over-current circuitry.

I am not sure why that would cause the controller to just output rubbish data. Once in this state any USB device plugged in is detected but fails when the AttachDevice function tries to schedule its first transfer. If I log any future attachment once in this state then after the port reset there is just random data on the bus - not even SOF packets. At least nothing my protocol analyser can hook onto and decode.

Mark

Re: USB Attach Failure i.MX28 Windows CE 6.0 Memory Stick

markwilliams — Thu, 25 Feb 2016 12:02:09 GMT

I am looking to see if I can output the QHead and Qtd list for the asynchronous schedule when the port is in the stuck state. The idea behind this to see if there is invalid pointers in the transfer schedule. At the moment I am not 100% sure where to do this - I need to fully understand the Microsoft driver structures to know what to output.

I am not able to run in a debugger connected to VS so using release builds and debug messages. The debug builds are also too bloated and slow - the timings can affect what we are trying to test.

Mark

Re: USB Attach Failure i.MX28 Windows CE 6.0 Memory Stick

markwilliams — Thu, 25 Feb 2016 12:35:51 GMT

I have been looking in more detail at the USB protocol analyser output. On a failed attach there is random data on the USB bus shown in my protocol analyser. But when I look at the timing and bit levels I can see that they are produced every 1ms (USB frame duration at full speed) and each attempt at a transfer starts with a valid SYNC packet of 0x01.

The PID that follows the SYNC is the random aspect and as the protocol analyser does not detect a valid PID it just shows 'data'.

I have included an example below and every packet starts with a valid SOF but then a random PID:

So to me the controller is consciously trying to send something but that something has an invalid PID which helps strengthen the fact that it might not be real data.

Occasionally (by chance) the PID field happens to have the second four bits as the complement of the first four and match a valid PID so my analyser shows an attempt at decoding it, but is is not a real packet. The random data just happened to have something that matched a valid PID. The rest of the packet is missing because it wasn't intentional. Anyway in this case it happened to look like the start of a PING?!

So I now have to understand what puts the controller in this weird state and how to prevent it or have a recovery mechanism on device re-insertion to save having to power cycle.

Initially it could be one of the Erratum such as suggested by Yuri (although according to the iMX6 version of this erratum ERR006308 the host controller only sends SOF packets in this state but I am not seeing valid SOF.)

The only other erratum is Errata 2858 USB controller may access a wrong address for the dTD (endpoint transfer descriptor) and then hangs. I have tried using other SBURSTCFG modes to work around this with no luck but perhaps there is something in postponing freeing the last TD in case memory could be re-used while the controller is still pointing to it.

Hopefully someone can help me understand this or if there are any fixes applied to other BSPs that I may need. Windows CE support is not as readily available as Linux though!

Mark

Re: USB Attach Failure i.MX28 Windows CE 6.0 Memory Stick

karina_valencia — Fri, 26 Feb 2016 16:23:13 GMT

Deactivated user can you help to review this case?

Re: USB Attach Failure i.MX28 Windows CE 6.0 Memory Stick

markwilliams — Tue, 01 Mar 2016 14:39:06 GMT

I tried setting the USBMODE SDIS bit as per Errata ERR006308 but I was still able to get the USB port to hang in the same way with several insertions / removals of memory sticks.

To be honest the iMX6 errata for this same issue says that the controller outputs SOF in the stuck-state which is not the same as my issue where it is outputting random data.

I am therefore still looking for the root cause of this.

Mark

Re: USB Attach Failure i.MX28 Windows CE 6.0 Memory Stick

karina_valencia — Tue, 01 Mar 2016 15:40:29 GMT

Deactivated user do you have an update of this case?

Re: USB Attach Failure i.MX28 Windows CE 6.0 Memory Stick

adeneo-embedded — Tue, 01 Mar 2016 18:33:55 GMT

Hi Mark,

Currently, we have one of our engineers assigned to this case. We will provide an update to this thread as soon as we can.

Thanks!

Adeneo Engineering Team

Re: USB Attach Failure i.MX28 Windows CE 6.0 Memory Stick

markwilliams — Tue, 01 Mar 2016 19:03:34 GMT

Thank you adeneo! I hope you can help!

Re: USB Attach Failure i.MX28 Windows CE 6.0 Memory Stick

adeneo-embedded — Thu, 03 Mar 2016 01:55:11 GMT

Hi Mark,

Here is the results of our investigation.

USB HOST CONTROLLERS

iMX28 has two USB host controllers, USB0 w/ OTG and USB1 with host support only.

It may be important to know which port is being used when failure happen, specifically if OTG is involved.

FSL BINARIES and MSFT QFEs

The binaries in the image (as the call stack would be) are:

USBDISK6.DLL

– from …\PLATFORM\COMMON\src\SOC\common_FS_V2\MS\USBCLASS\USBDISK6\*

USBMSC.DLL

– from PUBLIC branch (therefore up-to-date via MSFT QFEs)

USBD.DLL

– from PUBLIC branch (therefore up-to-date via MSFT QFEs)

Hcd_hsh1.DLL corresponding to EHCI.DLL of PUBLIC branch

– from …\PLATFORM\iMC28-EVK\SRC\drivers\USBH\HSH1 and

– from …\PLATFORM\COMMON\src\SOC\common_FS_V2\MS\USBH\*

If OTG selection ”pure host” from OTG Catalog group is made

Hcd_hsotg.DLL

– from …\PLATFORM\iMC28-EVK\SRC\drivers\USBH\HSOTG

It makes sense to compare the folders in …\PLATFORM\COMMON\src\SOC\common_FS_V2\MS\USBH\ to those in …\PUBLIC\COMMON\OAK\DRIVERS\USB\HCD\USB20\ in order to detect if any QFEs from MSFT need to be imported to FSL’s branch; KB2516902 and KB980435 are involved.

Likewise …\PLATFORM\COMMON\src\SOC\common_FS_V2\MS\USBCLASS\USBDISK6 should be compared to …\PUBLIC\COMMON\OAK\DRIVERS\USB\CLASS\Storage\Disk\SCSI2 with regard to KB2635840 and KB980435, even if this binary is unlikely to be causing the damage.

Once this source analysis is complete, and MSFT QFEs ported to FSL branch, a new trial run shall be executed.

= = = = =

One can only speculate that the fix could be as simple as adding "volatile" qualifier to a variable in some USB structure which is used by two different threads yet considered never-changeable; alternatively it could be as complex as hunting single bits in the USB memory structures or USB Host Registers.

At this time the best suggestion would be, to determine whether the fault is hardware or software related. The setup has USB probe attached which sniffs out the traffic. Further, it has been determined that the failure occurs at certain specific moment in the USB attachment state machine, and debug breakpoint could be inserted right there. Thereafter, if USB Host Controller runs properly, when the host is in break state in debugger no USB packet traffic would happen; if babble is observed on the wire while host is in break state then it is the hardware at fault. If, on the other hand, USB wires are calm while the target device is in break state, then the babble is definitely caused by bad software handling. As mentioned before, the odds are that SW is at fault and "volatility" may be applicable.

Thanks!

Adeneo Engineering Team

Re: USB Attach Failure i.MX28 Windows CE 6.0 Memory Stick

markwilliams — Thu, 03 Mar 2016 09:03:11 GMT

Hi,

Thank you for your update. I have already been through porting the Microsoft QFEs from the public folder to the MS folder within the BSP. This was something I noticed some several years ago when I realized that the Freescale BSP had a clone of the Microsoft driver code and no QFEs would be applied. I painstakingly performed diff-merges on all of the cloned files. The only QFE I haven't ported is

KB980435 Issue 1

When you use the suspend or the resume feature on a USB device, the Windows Embedded CE 6.0-based USB client driver is not notified of a remote wake-up event.

We are not using suspend/resume on windows CE. However I will look at porting this across just to be sure.

With regards to the driver this is on the host-only port.

Once the USB controller is in this state the random data bytes are produced for any USB device plugged into the port. I therefore believe that the host port is generating the sync (every ms) and then a random byte after it. A USB device should not send any data in response to the sync byte as it requires a PID after to instruct it what to do (IN/OUT/SETUP). So for all devices to have the same random data it is most likely that the USB host is generating it. It would be odd for a collection of devices to simultaneously start outputting a single byte of data following a sync byte.

In normal operation for the USB controller to be outputting data periodically it must have something scheduled to transfer, potentially with a corrupt pointer. I am wondering if printing out the transfer queue pointers/structures would help identify if the controller has a bad transfer queue set up?

There is another errata that concerns met: Errata 2858 USB controller may access a wrong address for the dTD (endpoint transfer descriptor) and then hangs.

I have tried using other SBURSTCFG modes to work around this with no luck but perhaps there is something in postponing freeing the last TD in case memory could be re-used while the controller is still pointing to it. It seems to make sense to me that if the memory is re-used before the controller has finished with it then the controller could be issued with bad pointers in its transfer queue and start babbling out data.

The linux world has this 'postpone free last Td' fix. Have you implemented this for your versions of the Windows CE USB drivers in your BSPs? Could you advise on how to do this?

Kind regards, Mark

Re: USB Attach Failure i.MX28 Windows CE 6.0 Memory Stick

adeneo-embedded — Fri, 04 Mar 2016 20:57:46 GMT

Hi Mark,

The scenario is very clear now, just one element is missing: whether the target image has Hcd_hsotg.DLL in it.

I was able to build two usable images from the iMX28-EVK BSP; I inspected BIB/REG files of both.

Both possible HOST-only selections are outlined below; it would be interesting to find out if OTG has any impact at all.

(1) USB HOST only build without OTG

One of the builds had just this selection from Freescale i.MX28 EVK: ARMV4I Catalog:

USB Devices

USB Host Device

[X] High Speed Host

It had just Hcd_hsh1.DLL in it, and the BIB/Registry files were set accordingly.

;------------------------------------------------------------------------------

; PURE HOST Registry

; @CESYSGEN IF CE_MODULES_USBHOST

; @CESYSGEN ENDIF CE_MODULES_USBHOST

; @CESYSGEN IF CE_MODULES_USBHOST

[HKEY_LOCAL_MACHINE\Drivers\BuiltIn\HCD_HSH1]

"Prefix"="HCD"

"Dll"="hcd_hsh1.dll"

"Order"=dword:15

"Class"=dword:0c

"SubClass"=dword:03

"ProgIF"=dword:20

"MemBase"=dword:80090000

"MemLen"=dword:00001000

"irq"=dword:5C

"HcdCapability"=dword:4 ;HCD_SUSPEND_ON_REQUEST

"OTGSupport"=dword:0

"OTGGroup"="01"

; @CESYSGEN ENDIF CE_MODULES_USBHOST

;

; END OF PURE HOST Registry

;------------------------------------------------------------------------------

(2) USB HOST build with pure host OTG

The other build had a radio button from the OTG group also checked in addition to the selection above:

USB Devices

USB High Speed OTG Device

( ) High Speed OTG Port Full OTG Function

( ) High Speed OTG Port Pure Client Function

(x) High Speed OTG Port Pure Host Function

It had both Hcd_hsotg.DLL and Hcd_hsh1.DLL in it, and the BIB/Registry files were set accordingly:

;------------------------------------------------------------------------------

; PURE HOST Registry

; @CESYSGEN IF CE_MODULES_USBHOST

[HKEY_LOCAL_MACHINE\Drivers\BuiltIn\HCD_HSOTG]

"Prefix"="HCD"

"Dll"="hcd_hsotg.dll"

"Order"=dword:15

"Class"=dword:0c

"SubClass"=dword:03

"ProgIF"=dword:20

"MemBase"=dword:80080000

"MemLen"=dword:00001000

"irq"=dword:5D

"HcdCapability"=dword:4 ;HCD_SUSPEND_ON_REQUEST

"OTGSupport"=dword:0

"OTGGroup"="01"

; @CESYSGEN ENDIF CE_MODULES_USBHOST

; @CESYSGEN IF CE_MODULES_USBHOST

[HKEY_LOCAL_MACHINE\Drivers\BuiltIn\HCD_HSH1]

"Prefix"="HCD"

"Dll"="hcd_hsh1.dll"

"Order"=dword:15

"Class"=dword:0c

"SubClass"=dword:03

"ProgIF"=dword:20

"MemBase"=dword:80090000

"MemLen"=dword:00001000

"irq"=dword:5C

"HcdCapability"=dword:4 ;HCD_SUSPEND_ON_REQUEST

"OTGSupport"=dword:0

"OTGGroup"="01"

; @CESYSGEN ENDIF CE_MODULES_USBHOST

;

; END OF PURE HOST Registry

;------------------------------------------------------------------------------

The suspicion of runaway qTD is very reasonable; however, time delay may be just workaround. Nothing like that has been ever implemented in MSFT or FSL USB port drivers.

Keep in mind that there are at least three threads (in order of low-to-high priority) which have access to queues & transfers:

USBD calling thread;

USBD event callback thread;

HC IRQ handler.

Each shared memory resource between these threads should be “volatile” qualified, to prevent optimizing compiler from caching a pointer or value on the local stack.

Another technique which might be applicable (albeit USB descriptors should always be allocated in non-cached memory) could be, CacheRangeFlush() call after release of queue descriptor.

= = = = =

All-in-all, I cannot imagine finding the root cause of the problem without debugging.

To confirm or deny the suspicion of time-related issue while freeing transfer descriptors, a debug session is a must.

My recommendation would be to focus on the function void CHub::AttachDevice() in <WEC7root>\Platform\CommonSRC\SoC\Common_FSL_V2\MS\USBH\usb2com folder.

Setting up ZONE_ATTACH and ATTACH_DETAIL to obtain traces during device attach process might also be helpful.

Needless to mention, USB Analyzer should be connected all the time and live results should be monitored wile attachment state machine is executing.

The state machine has only three stages before reaching DEVICE_DESCRIPTOR stages.

The stage immediately preceding DEVICE_CONFIG_STATUS_SCHEDULING_GET_DEVICE_DESCRIPTOR_TEST is no other but DEVICE_CONFIG_STATUS_RESET_AND_ENABLE_PORT.

Incomplete or improper reset of a port is very likely to have dire consequences, and this triage scenario may help:

1. Build RETAIL image with optimizations disabled for USB2COM files. Both KITL and DEBUGGER must be enabled for the image.
2. Set breakpoints
at line 1700, DEVICE_CONFIG_STATUS_OPENING_ENDPOINT_PIPE case; and
at line 1775, DEVICE_CONFIG_STATUS_GET_DEVICE_DECRIPTOR_TEST case;
then let run until the failure happens; that will confirm babble begins after few attempts in-between these two stages;
3. Reboot target, disable breakpoint at line 1700 and set instead one
at line 1753, DEVICE_CONFIG_STATUS_RESET_AND_ENABLEPORT case;
pay specific attention to line 1765, BSPHostDisconnect(TRUE); even put breakpoint there too, just to see if it gets invoked and when.
4. Let run and try to reproduce; see if babble start in-between the lastly set breakpoints.
If this happens, then the failure may only happen on a couple of code lines.
5. Alternatively, step into and through the code of ResetAndEnablePort(port) function, and observe if this “slow-motion” effectively provides workaround.

There is exactly one pipe – the control pipe 0 – which is employed in the process; all its descriptor allocations may be observed while at breakpoint and any corruption of pointers/descriptors can be detected.

Before and after reset, a dump of HC port registers may also be useful for differential analysis.

Thanks,

Adeneo Engineering Team

Re: USB Attach Failure i.MX28 Windows CE 6.0 Memory Stick

markwilliams — Sat, 05 Mar 2016 20:35:39 GMT

Thanks adeneo for such a detailed response!

We are using the host-only port and the hcd_hsh1.dll. The usb memory sticks are being plugged into this port which is limited to full speed operation.

We have an internal micro usb connector hidden inside the product connected to the otg capable port for os loading. The driver for the otg port is included in the image but prevented from loading at start up. This was so that if we wanted to use the port our app could start the otg driver. However we do not use this.

So only the hcd_hsh1.dll should be active.

From my analysis of the driver I agree this will be difficult to track without debugging. sadly the release product does not have an Ethernet port for connecting to VS. For debugging this I have been turning various debugmsg to retailmsg and printing out variables on the debug serial port - not ideal for this type of issue I know!

What I am unsure about is if the error state is created when on removal or when the device is next inserted. I.e. is the dequeue failing or setting up the first control transfer. I was hoping to print out the qH list on attach after the port reset and before the first control transfer (when it fails to attach it doesn't get past the first control transfer and I do not see any valid data on my USB analyser).

As there are no other usb ports or devices simultaneously connected the async queue should be in an empty state on attachment of a new device. It would be good to verify this on connect. This won't necessarily point me to the root cause though.

Annoyingly once in this state no other devices work. At the very least it would be good to ensure the async queue is fully reset on failure.

Thank you again for your help. I will keep this updated and work on this next week.

Mark

Re: USB Attach Failure i.MX28 Windows CE 6.0 Memory Stick

markwilliams — Wed, 09 Mar 2016 21:13:38 GMT

I have been continuing to debug but with no luck. I decided to search for WEC7 updates to do with USB. Although we use CE 6.0 I am sure the driver will have been used as a base in WEC7 so there may be fixes applied which haven't been released for CE 6.0.

I found this:

FIX: USB host cannot enumerate new device after unexpectedly removing an active USB device in Windows Embedded Compact 7

Symptoms:

Assume that you remove an active USB device from Windows Embedded Compact 7 unexpectedly. Then, the USB host cannot enumerate new devices any longer.

Cause:

The issue occurs because the USB host controller is constantly trying to finish a bulk transfer to the removed device. Because of this, further asynchronous transfers (Bulk, Configure) are not processed any longer. The USB host controller sets the Transfer Error Flag on the transfer, but neither stops the transfer nor triggers an interruption.

This seems to be fixed in Trans.cpp:

Trans.cpp

56,043

15-Oct-2014

09:08

Public\Common\Oak\Drivers\Usb\Hcd\Usb20\Ehci

From the description above this describes my issue - I remove a USB device and sometimes end up with a locked up port sending data.

To save me setting up a new VM to download compact 7 and ultimately this update, could Adeneo kindly do me a favour and have a look to see what changes were made in trans.cpp for KB3009114 and let me know (assuming you already have a machine with Compact 7 and the latest updates!).

Thank you in advance! Hopefully the above issue also applies to CE 6.0 too and I can back port it.

Mark