USB reconnect problems on K26

[aescov]

Hi

on our custom K26 board we are experiencing an issue when trying to reconnect USB after initial connect.

Board is self powered, but the USB part’s are power via VREGIN connected to VBUS.

Software is based on KSDK 2.0

On all boards the initial USB enumeration works, but on some boards if we disconnect and reconnect usb. The enumeration procedure fails when the host request the device descriptor.

We detect the present of the USB cable with a GPIO interrupt, and USB stack is initialized/deinitialized based on the state of this pin.

The issue can be fixed by constantly powering the VREGIN from a local source, but we would like to avoid this in order to save power when USB is not connected.

Investigations so far could indicate the USBHS controller or PHY is not in a valid state at the second connect attempt.  If I manually deinitializes the USB stack prior to disconnecting the USB scale it also works perfectly. Also if deinitialize and initialize the stack with the USB cable plugged in it works as expected.

I have tried resetting the PHY and controller before reinitialization of the USB stack after VBUS has become present again, but this does not seem to make any difference.

I have not had a chance to put on a USB analyzer yet, but I can see that the stack recognizes the reset and GetDeviceDescriptor, but it looks like that the TX part of the USB isn’t working proberly since the host issues new reset shortly after.

Any suggestion are welcome.

[cutworth]

Hi Anders,

I am still working with design team and USB stack team to find root cause. 

Hao

[aescov]

Hi Hao   

Sorry to push, but are there any news on this issue. ?  We currently holding back release of new PCB version due to this issue.

Br  Anders

[cutworth]

Hi Anders,

There is not much progress here. We still have no clue on why this does not work. Design team suggested to add delays after detecting VBUS event before USB PHY init. But this does not work. I am now diving into the USB stack code to look at where could go wrong. Sorry for not getting you some solution yet.

Hao

[aescov]

Hi Hao

Any progress on your side ?

I have tried to get some priority on this issue by raising this issue via our distributor  (Arrow). Hopefully this will help speed thing up, and make the design team look into this.

Br Anders

[cutworth]

Hi Anders,

No, there is not progress on my side. I will push design team and stack team to look at this. Really sorry for this. 

Hao

[cutworth]

Hi Anders,

I have found the root cause for my VBUS attach and detach code not working. Actually the ADC compare value I set is not correct. Initially I set compare value for VBUS attach event as 32000, with VREFH=3.3V and 16bit ADC, this means VBUS=3.2V which is not enough for  VBUS valid session, this value is still not enough for valid USB regulator output and for PHY PLL lock.

Also ADC compare value for detach point is set too low, initially it's set as 400. At this level VBUS is already very low as well as USB regulator output, and call following function is meaningless in this case.

USB_DeviceStop(g_msc.deviceHandle);
USB_DeviceClassDeinit(CONTROLLER_ID);
USB_EhciPhyDeinit(CONTROLLER_ID); 

After changing the ADC compare value to appropriate one, re-enumeration works now.

Please check attached C code.

guojia‌

Hao

[aescov]

Hi Hao

Thank for your answer. I have studied you solution, and noticed that what you actually do is to detect VBUS loss before the hardware block shuts down due to low voltage. 

In my mind this is more like a workaround, than a true fix for this issue.  Also i don't think this explain why we see a difference when running 16 MHz  or 24 Mhz XTAL.

I will check with my HW designer to see if this workaround is at all feasible for our solution, but anyway i think we need more insight from your design team to understand  the root cause for this issue, and what actually goes on in the USB blocks when valid VBUS is removed before the block are safely shutdown,  and why the blocks are not capable of recovering when VBUS is applied again.

Br

Anders

[cutworth]

Hi Anders,

Sorry, but I did not find any code related to how you use SW3 to initial and de-initial USB stack in attached code. Also it's not clear how you use GPIO for VBUS detection.

Hao

[aescov]

Hi 

SW3 is used to emulate VBUS detection. It is not connected to VBUS on the TWR board, but since the GPIO VBUS detection will be asynchronous to the USB block anyway, this setup can be used to replicate the issue.  As you now the problem is that it only works ( 24MHZ XTAL ) when deinitializing the stack prior to disconnecting VBUS, which in a real world application is not possible.

SW3 is simply triggering a GPIO interrupt that will post an event to UsobApp task, that will toggle the USB stack on off independent of the actual USB VBUS/VREGIN state.

If you load the code into the TWR board (compiled with correct XTAL define), and follow the steps described above, you should be able to replicate the issue when mounting 24MHZ  XTAL.

Anders

[cutworth]

Hi Anders,

OK, I see. Sorry I forgot that you are using freertos demo insted of baremetal one. I looked at the bm code so got confused.

Hao

[aescov]

Hi Hao

Link below points to a zip file containing register dumps in working and non working state on my custom board with 24 MHz XTAL.

Unfortunately my eclipse did not allow me to dump to a data file, so i have made screen dump of the register view.

Let me now i you need further information

Br 

Anders

[aescov]

Hi

Thank you for your feedback, i am out of office today, but will try to dump the registers when i am back tomorrow

Regarding VBUS detect this is done via GPIO pin in our custom design, but as described i am not able to get the USB working again after disconnecting.  Only if I deinitializes the USB blocks prior to removing the cable it is possible to reenummerate when inserting cable again. But as the cable can be removed at any time, this is not a valid workaround.

Br

Anders

[aescov]

The behavior i see is in my application

1. Idle
2. USB cable plugged in
3. Cable connect detected -> USB stack initalize
4. USB stack in initialized ->  Pull up enabled by the USB stack and high-speed handshake  and enumeration is performed successfully
5. USB cable unplugged 
6. Cable disconnect detected and USB stack in deinitialized.
7. USB cable plugged ( At this time I see DP high eventhough stack is not yet initialized, and the host inits handshake procedure)
8. Cable connect detected -> USB stack initalized
9. Enumeration fail

If i de-initializes the stack prior to 5, then the DP is not high when re-plugging the cable and the device enumerates correctly.  Also if i leave the cable plugged i can deinit/init the stack without any problems.

As mentioned i can recover from this state by bringing the device into a STOP state, so am i am looking for at way to safely reset the USB block during normal RUN.

Br Anders

[aescov]

Hello Hao

Thank your for your reply

I am using the stack that is supplied with the KSDK 2.0.  By the way I recently tried to generate a new SDK with MCUXpresso generator, to see if anything was updated, but it did not include the USB stack for the K26.

The USB part of the schematics looks like this.  

As described the reconnect issue is not present  on all units, and does not occur at all if I manually deinitializes the stack prior to disconnecting the USB cable. When the unit is in error state i am not able to recover until i reset the k26.

/Anders

[cutworth]

Hi Anders,

K26 is in same family as K66 or K65, so you can refer to either FRDM-K66 board or TWR-K65 board SDK package.

When you remove VBUS power, both VREGINx are off based on your connection and VREG_OUT will not provide 3.3V any more and this will cause USB PHY unlock and USB controller in incorrect state, that's why you need to deinitialize USB stack before disconnecting USB cable. You have used some GPIO to detect VBUS, right?

Hao