USB composite device examples

[biafra]

Hi everyone,

Currently I'm working on TWR-K65F180M, KDS 3.2.0 and KSDK 2.0.

I'm testing the USB composite device examples (MSC + CDC and HID mouse + HID keyboard): they work fine if I use the USB0 controller (FS) (as they come in the package), by plugging the cable in the USB connector in the TWR-SER board (J14 connector).

But if I change the usb_device_config.h file to use the USB1 controller (HS)

USB_DEVICE_CONFIG_KHCI from 1 to 0

USB_DEVICE_CONFIG_EHCI from 0 to 1

and I plug the cable in the USB connector in the TWR-K65F180M board (J15 connector) the examples work only the first time I plug the cable: if I unplug the cable and then I plug it again, the device isn't discovered and it isn't discovered until I reset the device.

The device works (with both examples) only the first time it is connected.

Did anyone find the same behaviour?

Many thanks

Biafra

[jorge_a_vazquez]

Hi Francesco Bianchini

Sorry for the late reply, I am working in your issue. I ran the example in FS and in HS, I got similar behavior that you, but in my case when I'm running it in HS sometimes It works when I re-plug the cable and sometimes it doesn't. I checked the stack and It seems that there are some macros and functions that control when the device is disconnected. Now I'm consulting your case with some colleagues and I'll inform you any update.

Have a great day.
Jorge Alcala

[biafra]

Hi Jorge,

Thank you for your answer.

Meanwhile inspecting the code I discovered a bug.

In the file fsl_uart_freertos.c at line 134 the statement:

        vEventGroupDelete(handle->rx_event);

should be:

        vEventGroupDelete(handle->tx_event);

Shouldn't it?

The same bug in is the file fsl_lpuart_freertos.c at line 134.

Many thanks

Biafra

[jorge_a_vazquez]

Hi Francesco Bianchini

About the bug that you discovered in the UART freertos driver, I already check it and I report it to the developers, Thanks for telling us about it.

About USB example, we found the problem related.

The software stack is written assuming that VBUS is already present and that the USBPHY is powered with the PLL locked and ready to go. We recommend that you have power to the USBPHY anytime the processor is powered. If you are a bus-powered USB device, this is easy because the CPU power would be derived from the host VBUS.

There are two VBUS inputs to the PHY, but there is also an errata where if you use both inputs they need to be the same (see e9359 here: http://cache.nxp.com/files/32bit/doc/errata/KINETIS_K_0N65N.pdf ) So it isn't as easy as powering one VBUS so that the USBPHY has power and then using the second one for the host VBUS, due to this we recommend that you power both VBUS inputs all the time (or at least when the processor is powered up).

If you check the schematic, there is the jumper J23, and here VREG_IN0 and VREG_IN1 are powered by ELEV_USB_VBUS and ONBOARD_VBUS, and when you are running the example in FS mode ONBOARD_VBUS can be power by miniUSB_VBUS or P5V_ELEV (through Jumper J36), but when you are running the example in HS mode, ONBOARD_VBUS is not power until you connect Micro USB (depending on how you have J36).

We realized of this because If we had connected TWR_SER with TWR-K65 the problem did't happen, so we realize that with TWR_SER connected the MCU_VREGIN0 was connected with P5V_ELEV through Jumper 36, so even when we disconnected MICRO USB (J15), MCU_VREGIN0 was always powered up and the example didn't fail.

Hope this information help you.
Regards
Jorge Alcala

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