USB reconnect problems on K26

aescov · ‎01-16-2017

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.

jia_guo · ‎03-31-2017

Anders:

May I know the customer name and the industry? Are you FAE?

Thanks.

aerkenemesis · ‎08-15-2017

We are experiencing exactly the same problem with our K65F18, however it is already in production and we have a 12MHz crystal. We have no ADC connection to the VBUS so we cant use the hack Anders used to get it working. We are using generated code from the processor expert (usb_1.6.3 middleware).

Best,

Simon

jeffsimons · ‎07-05-2018

Hi,

Did you ever find a solution. I have the same reconnect problem on K66.

Regards,

Jeff

aescov · ‎07-05-2018

Hi Jeff

Unfortunately we did never find the root cause for this problem. We are able to live with the ADC hack in our solution, but i i think NXP should get to the bottom of this since it seems to be a very critical issue for self powered USB device applications.

Best regards

Anders

jeffsimons · ‎07-06-2018

Hi Anders,

I agree, its a big flaw.

Thanks for the reply, much appreciated.

Regards,

Jeff

aescov · ‎01-24-2017

Hi

We have now mounted a 16 MHz XTAL on one of the custom boards that was failing.

With that mounted and the software configured to run off 16 MHz XTAL we have not been able to replicate.

As this is getting getting urgent for us now, I would kindly ask you to forward the info from this thread to the design team, to get some better understanding of why the USB blocks are failing when using using 24 MHz xtal and not 16 MHz XTAL, when removing power from VREGIN.

It is not an option to mount an 16 MHz xtal on the product due the size restrictions, so it is important to find a robust solution running af 24 Mhz XTAL.

Br

Anders

aescov · ‎01-18-2017

Hi Hao

The TWR board is in default state, which means that J9 is shorted 1-2 and 3-4. ( VREGIN0 connected to VBUS)

J9 is in the 5-6 position. Board is hence powered from the K20 mini USB.

This power setup is similar to my custom board.

I find it hard to accept that it should be required to deinit the USB stack prior to disconnecting the cable, for two reasons.

First this would mean that you would have to predict when the user disconnect the cable, and would make it difficult to design as self powered device that allows usb to be reconnected.

Secondly the setup based on the reference source code seems to work with the 16 MHz XTAL mounted on the TWR board, but not when a 24 MHz XTAL is mounted. For the reference project the stack is only initalized during startup and i not reinitialized on reconnect. However USB reconnects work as expected when runnning of 16 Mhz XTAL.

/Anders

cutworth · ‎01-19-2017

Hi Anders,

The board setting on your board is still different from what is on K65 tower board. On K65 tower board, you are not connecting VREGIN0 and VREGIN1 together, but on your board, they are connected together. I suppose you are not connecting TWR K65 in tower assembly so ELEV_USB_VBUS is 0V, right?

There is one errata related to current limiter behavior of USB regulator when the VREGINx pins are different voltage. This may cause temporary VREGOUT drop. I am not sure if this is related to your issue. When you say 24MHz clock input does not work and 16MHz clock can work, what did you see on PC host? Is it USB enumeration fail?

http://www.nxp.com/assets/documents/data/en/errata/KINETIS_K_0N65N.pdf

For self-power case, you can still power USB regulator to keeping USB PHY always working. You can connect VREGINx to 5V on your board instead of from VBUS or you can connect VREGOUT directly to 3.3V with VREGINx floating.

Hao

aescov · ‎01-20-2017

Hi

I am aware that only one VREGIN pin is powered on the TWR board, but as I was able to replicate the issue by just changing to 24 MHZ XTAL, i did not try to power both on this board. Also i am aware of the errata and have tried to disable the current limit during initialization, but i did not change anything.

When having a 24 Mhz XTAL mounted on the TWR board I see enumeration fail when re plugging the USB cable. The situation looks similar to what i see on my custom board in that RX seem to be working, but is TX not.

With 16Mhz XTAL on the TWR board i was able unplug/plug the cable an d the device enumerated gain.

On thing that trigs me is that in the demo software the stack is only initialized during startup and there is no detection of the cable state. As it is able to reconnect (16Mhz mode) i assume that the state of the controller PHY is maintained in some way even though the VREGIN disappears. Can you conform that.

Regarding powering the VREGIN/OUT from local source, I would like to avoid this since it leads to higher current consumption (0.5mA@VREGIN) in the case when no USB is connected.

Br Anders

cutworth · ‎01-16-2017

Hi Anders,

You are right, what you experienced looks related to HS USB PHY in incorrect state when you unplugged USB cable. HS USB PHY has internal PLL which requires stable 3.3V on USB regulator output. The USB regulator has two inputs VREGIN0 and VREGIN1 which should come from VBUS of USB connector.

Are you using your own USB stack code or you are using USB stack inside Software Development Kit for Kinetis MCUs|NXP ?

Could you share how you connect VREGINx with VBUS? Are you connecting only one of the VREGINx or both to VBUS on USB connector?

Hao

aescov · ‎01-17-2017

Hi again

I have investigated the issue further today, and have been able to replicate the issue with on the TWR-K65F180M, using the dev_msc_sdcard_freertos_twrk65f180m demo project.

Trying to make the setup as similar to our custom board as possible I changed the XTAL to a 24 MHZ as we have in our design.

In order to make the demo work i changed BOARD_XTAL0_CLK_HZ to 24000000U and the PLL prdiv to 2 (divide by 3).

After doing these changes i see the exact same behavior with the example code and K65 reference platform.

Hope this info will be helpfull to figure out whats going on

Br Anders

cutworth · ‎01-17-2017

Hi Anders,

For TWR-K65 board, which jumper setting you used to replicate the issue? Did you connect it in a tower assembly or used TWR-K65 standalone?

Let me know how you connect J23 and J9.

Hao

aescov · ‎01-19-2017

Hi Hao

After having the device connected to a USB analyzer i can confirm that the USB TX part is not not working after reconnect.

From debug traces from my device and the USB analyzer i can see that the reset and GetDeviceDescriptor commands are received by my device, but the answers does not get onto the line, even though the date are copied to the endpoint. The host retries GetDeviceDescriptor command a number of times before reporting unknown devices.

Another observation is that when connecting the cable again after having disconnected with controller and phy active the 1.5K pull up on DP seem to be on forever on. Also i cannot control the pull up with the USBCMD->RS bit as expected.

The only way i have found to recover from this state, is by entering a stop mode (VLLS0/1). Then after wakeup the USB blocks are working again and enumeration succeeds. In some use case this will be feasible but i don't find this to be a very nice and probably not one that generally can be used in the product.

Are the any reliable way to reset the USB block apart from the reset bits in the software reset bits in USBCMD and USBPHY_CTRL

Hope this additional observation will help finding a solution.

Br Anders

cutworth · ‎01-19-2017

Hi Anders,

I do not quite understand the part you say 1.5k pull up always enabled after disconnect and reconnect. HS USB works at first as FS device and with 1.5k pullup enabled, then it goes through high speed handshake and remove the pullup. So you mean you never see the high-speed handshake on USB bus?

Hao

aescov · ‎02-09-2017

Hi Hao

Any news on this issue. We really need to know if there is a workaround that will allow us use 24Mhz XTAL or we need to redesign for 16 Mhz

Br

Anders

cutworth · ‎02-09-2017

Hi Anders,

Sorry, I am not following up with this ticket for some time, just got back from CNY holiday. I will try to look at this today by replacing 24MHz XTAL.

Hao

cutworth · ‎02-10-2017

Hi Anders,

I am trying to duplicate your issue by using ADC signal on TWR K65 board to detect VBUS attach and detach event. But I still got problem to successfully re-enumerate USB with reconnection of USB cable. I have attached associate code. When I see the failure, I see USBHS controller status incorrect, SUSP bit is set in PORTSC1 register when I reconnect USB cable. I am still checking why this happened.

You mentioned you have no problem re-enumerate the device using VBUS detect method, can you share your code? Also when you see the failure, can you dump both USBHS and USBPHY register?

Hao

aescov · ‎02-15-2017

Hi again

I have changed the "usb_device_msc_sdcard" SDK 2.0 example so that it now is possible to toggle the USB stack on/off via SW3 on the TWR board

Please find attached zip file.

When the code starts up up from reset the usb stack will be initialized and will enumerate if (or when) USB cable is connected.

By pressing SW3 the USB stack state can be toggled on/off, and the device successfully re-enumerate as long as the cable is attached.

When running off 24 MHz XTAL the failure state can be entered by removing the cable prior to deinitializing the stack.

Power device up and attach usb cable - device enumerates successfully.
Press SW3, USB stack de-initializes.
Press SW3, USB stack initializes and device enumerates successfully.
Removed USB cable.
Press SW3 to de-initialize stack
Insert USB cable
Press SW3 - to initialize USB stack - ( Enumeration failure occurs, and reset/stop mode required to recover)

Note, the above sequence seem to work perfectly when running same code on a board with 16 MHZ XTAL ( #define BOARD_XTAL0_CLK_HZ 16000000 and recompile)

Hope this will help you replicate the issue.

Best regards

Anders

cutworth · ‎02-17-2017

Hi Anders,

Just tried your freertos code and found even with 16MHz crystal, I do not see it can enumerate successfully at step 7. It failed too. I will compare your code with my VBUS detection code. But I think both showed similar problem.

I am still trying to find out why re-enumeration failed even I de-initial and re-initial USB PHY PLL and USB stack with VBUS detection method.

I will work with our design team on this next week.

Hao

aescov · ‎02-23-2017

Hi Hao

Any news on this issue. ?

Br Anders