No USB connection on a kinetis MK26 custom board

[bartrijvers]

We use the MK26FN2M0CAC18R processor for a custom board we have made. On this board we have a USB High Speed (EHCI) USB composite mass-storage and CDC UART application. We've found one (broken) board to have become unresponsive on a Windows or Linux PC that has worked before.

I have another (working) board with the exact same hardware and software,which is working fine.

To simplify things for further analysis, I've run an USB CDC UART application that is derived from an example from the SDK, giving the same results.

On the broken device:

Using the JLink debugger, I can see that the driver initialization is all OK.

After the IRQ has been registered, the RS bit is set which results in a pull-up pulse on the DP line. I added logging in the ISR and function that handled the USB controls and I see that the USB_DeviceEhciInterruptReset call results in the isResetting flag being set. There is no more interrupt on USB or any post-initialization of the stack done by any piece of code after this.

Connecting this device in Ubuntu does not result in any kernel loggings.

On the working device:

After the IRQ has been registered, the RS bit is set which *does not* result in a pull-up pulse on the DP line.

The USB_DeviceEhciInterruptReset call results in a callc to the USB_DeviceNotificationTrigger(kUSB_DeviceNotifyBusReset) function.

It therefore appears the PortReset bit in the PORTSC1 is not set before the poll timeouts in the broken device.

What can cause this ?

Can I analyze any further from software point of view ?

I have tried to switch to the KHCI full speed USB driver but I can't get this to work, also not on the working device. Is there anything else I need to do in the usb device config file except enabling KHCI and disabling EHCI & rebuild from scratch ?

[bartrijvers]

Also sorry for the late reply, I was out of the office for some days.

We use Kinetis Studio 3.2.0 and we downloaded SDK 2.1.0 seperately for our software.

For the test:

I downloaded SDK 2.3.0 and added project dev_cdc_vcom_bm_twrk65f180m into Kinetis Studio. I enabled USB_DEVICE_CONFIG_EHCI and disabled USB_DEVICE_CONFIG_KHCI & compiled the application.

On a working device I now get COM56 on Windows and Terraterm echoes everything I type: OK

The Broken device however does not initialize a COM port in Windows.

I could debug until the USB_DeviceClassInit function was successful...

[bartrijvers]

Hello Mike, do you have any more ideas that we can check-out ?

[Hui_Ma]

First of all, sorry for the later reply.

I am checking this issue with Kinetis product team.

Could you let us know how many chips with this issue? Thanks.

best regards,

Mike

[bartrijvers]

We have 100 - 125 devices in total and only one has this problem currently. The first devices have been used for developments & testing about 9 months ago. After that, a batch of 100 has been made some 3 months ago. The problematic board is from this last batch and has used more or less frequent by the customer for evaluation.

One problematic board does not seem much but we need to make sure this is an incident rather than a first indication of more trouble to come.

Today we've sent the board back to the supplier for analysis, including X-ray and I'll post the results when we have them. Until that time, I cannot perform further tests of course.

[bartrijvers]

The two boards came back on Friday and I had some time to re-test yesterday. Both devices have been "visually inspected" and the processor was "reflowed". This did not solve the problem though. I attached more details but I will probably not get the time for further analysis due to change in priorities and cost of investigation...

[bartrijvers]

Could not find the attachment button in my previous reply,, so here it is.

[Hui_Ma]

Hi,

Thank you for the updated info.

From the test log info, the USB_STS register there shows the device was suspended.

I would recommend customer to submit a CQI requirement.

Please contact with your local NXP Distributor to return the failed part for further analysis.

Thank you for the attention.

Have a great day,
Mike

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

[Hui_Ma]

Thanks Bart.

Please help to updated that problem chip diagnostic report from the supplier.

Best regards,

Mike

[Hui_Ma]

Hi,

Due to the K26 develop board is TWR-K65F180M board, I do a test with MCUXpresso SDK V2.3 for TWR-K65F180M board about full speed USB as USB CDC device.

For the TWR-K65F180M board only provide the USB1 connection, it need to use TWR-SER board to connect USB0 of K65.

I test with [usb_device_cdc_vcom] baremetal project, it works for USB device config using KHCI (usb_device_config.h):

/*! @brief KHCI instance count */
#define USB_DEVICE_CONFIG_KHCI (1U)

Have a great day,
Mike

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

[bartrijvers]

Ah, I checked with our schematics and see that the USB0 DP and DM lines are not connected. This answers at least why the KHCI USB stack won't work on our board. It does not answer the EHCI USB 2.0 question however which is of most interest for us.

[Hui_Ma]

Hi,

About the MK26 high speed USB1 module, customer mentioned the broken board has worked before.

If you are using MCUXpresso SDK for MK26, please compare the USBHS module and USB-PHY module registers value difference between broken board and working board after APPInit() function.

If possible, please help to post related registers value here.

I also could check them with my side.

best regards,

Mike

[bartrijvers]

I attached a zip file with screenshots of my Kinetis Studio environment JLink debug session. It took me 4 screenshots to get all register values captured per breakpoint.

I captured the working board and the broken board, both before the RS bit is set and after the first IRQ is handled.

I hope it is useful. Since I broke my arm, operating a keyboard is challenging.

[Hui_Ma]

Hi,

Thank you for the registers info.

I compare the USBHS registers values, there without any difference prior SR bit set.

After the first IRQ, the working board will be detected as a high speed device with endpoint 0 setup;

while, the broken board will be detected as a full speed device without endpoint 0 setup.

The broken board doesn't switch to the high speed mode successfully.

Could you double check the board if there with any hardware issue with usb related circuit?

Thank you for the attention.

Have a great day,
Mike

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

[bartrijvers]

Hello Hui,

We did an optical inspection of the broken board and found nothing unusual.

Also analyzing electrical on DP and DM did not show specials (using an oscilloscope).

We use the 0.4 pitch BGA component by the way.

[Hui_Ma]

Hi,

First of all, sorry for the later reply.

If you are using the USB stack of MCUXpresso SDK software for TWR-K65F180M?

If yes, what's the MCUXpresso SDK software version?

Have you tried to use the latest MCUXpresso SDK software Rev 2.3.0 provided [usb_device_cdc_vcom] demo?

Have a great day,
Mike

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