Possibly hardware issue with USB

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Possibly hardware issue with USB

Jump to solution
15,439 Views
yuriydovgalyuk
Contributor III

Hi all

I need a help regarding troubleshooting of the USB issue.

I made 2 custom PCBs (MK22FN1M0VLH12), both have USB connector, routing is almost the same. Both PCBs are working fine, the firmware is absolutely the same inside both MCUs.

BUT, as soon as I connect a USB cable to PCB A, it stops working, generates hard fault (could be bus or usage fault), while PCB B is working fine and USB functionality works as expected.

Measures taken to solve the issue:

  • At the beginning I put 51Ohms terminator resistors on both PCBs. In this stage PCB A does not work, PCB B works fine.
  • Then I changed resistors to 33Ohms (as recommended) on PCB A, did not help.
  • Then I tried to remove resistors and short cut on PCB A, did not help, so I moved back to 33 Ohms.
  • Then I enabled MPU on PCB A and saw generates MPU errors, this is just an additional information

I attached pictures that show how PCBs are routed.

I need some ideas what to try more? Should I add pull-down 15kOhm resistors to data lines?

1 Solution
14,554 Views
yuriydovgalyuk
Contributor III

FINALLY!!!

Finally I confirmed the problem is in MCU hardware.

I used same CPU but from another batch, and it worked perfectly...

If you look at the picture, you will notice that labeling on not-working MCU is not that contrast as on working pieces. I had 2 MCUs with those non-contrast labels, USB do not work with them. When I use MCUs with good labels - no problems with USB.

So, I suspect Freescale made a batch of defect MCUs! Will now resolder PCBs...... But so much time waster for a ghost.....

20150527_173106.jpg

View solution in original post

0 Kudos
Reply
17 Replies
14,555 Views
yuriydovgalyuk
Contributor III

FINALLY!!!

Finally I confirmed the problem is in MCU hardware.

I used same CPU but from another batch, and it worked perfectly...

If you look at the picture, you will notice that labeling on not-working MCU is not that contrast as on working pieces. I had 2 MCUs with those non-contrast labels, USB do not work with them. When I use MCUs with good labels - no problems with USB.

So, I suspect Freescale made a batch of defect MCUs! Will now resolder PCBs...... But so much time waster for a ghost.....

20150527_173106.jpg

0 Kudos
Reply
14,554 Views
danielrosales
Contributor I

Hi Yuriy!

I guess that some batches of MK20 had problems and I tried next to stop breaking more chips and be able to use USB:

- Cut the VBUS pin which powers the USB peripheral (VREGIN not connected).

- Wire the VOUT33 directly to a 3.3 power supply

This basically is bypassing the USB internal power supply (its internal LDO). That won't burn any USB peripheral anymore. If you have MK20 where the USB is broken you won't recover them to work, at least de USB.

Best regards

14,554 Views
jeremyzhou
NXP Employee
NXP Employee

Hi Yuriy,

I'm glad to hear that you had figured out the root cause of the issue.

And I'd like to suggest that you can contact with the local FAE to share your doubt and I think they will handle it.
Have a great day,
Ping

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

0 Kudos
Reply
14,554 Views
yuriydovgalyuk
Contributor III

After some experiments I realized that the problem could be in crystal oscillator. I tried 24MHz instead of 8 and it seems that sometimes it works. Not always, but the device usually enumerated. Sometimes communicates (very seldom).

With 8 MHz crystal is was never communicating, even though sometimes it was enumerated.

So, I suspect a problem is somewhere in the region of USB (system) clocks....

Any ideas how to fix?

0 Kudos
Reply
14,554 Views
jeremyzhou
NXP Employee
NXP Employee

Hi Yuriy,

The USB FS OTG controller can't work normal when system clock frequency less than the 20MHz.

The controller also needs a 48 MHz clock and the clock options are shown below.

pastedImage_0.png


Have a great day,
Ping

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

0 Kudos
Reply
14,554 Views
yuriydovgalyuk
Contributor III

Hi jeremyzhou,

Yes, the core is running at 120 MHz (PLL) and i use 48 MHz for the USB.

The question is if I may have some side effects from soldering of the crystal. I use no resistors in my oscillator schematic (low power mode). And I use internal load capacitors. The oscillator is running fine at 8 MHz (checked with oscilloscope). But if there are some parasitic capacitance or resistance from flux that can influence the precision of the oscillator and thus - make USB communication broken at some point? Is there any way to check if the 48 MHz clock ok for USB?

NOTE: this happens only on MK22FN1M0. When I use MK22FN512 the system is running fine (same schematic, same PCB, external crystal used for USB).

I am really lost here.

BR

Yuriy

0 Kudos
Reply
14,554 Views
jeremyzhou
NXP Employee
NXP Employee

Hi Yuriy,

After I checked, MCU can't be able to output the 48 MHz through the CLKOUT pin.

I'm a litter confused with the issue, as the USB OTG module in the MK22FN1M0 and K22FN512 are totally same.

But he MK22FN512 can work it out, but MK22FN1M0 failed.
Have a great day,
Ping

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

0 Kudos
Reply
14,554 Views
yuriydovgalyuk
Contributor III

Hi jeremyzhou,

You are right, USB OTG are the same... However, it is required to disable MPU in MK22FN1M0 to make USB work. Not sure it is related anyhow...

But as I wrote before it is not that the communication not running, but rather the MCU raises exception (bus or usage falut interrupt) and here the communication stucks...

It is very very strage... I knew USB is not so straight forward, but here it is really some mystic.

0 Kudos
Reply
14,554 Views
jeremyzhou
NXP Employee
NXP Employee

Hi Yuriy Dovgalyuk,

According to your statement and after I've had a brief look through the attachments, I think this issue definitely was caused by the PCB fault.

However it's hard to point the exactly error with the PCB_B, it just looks as same as the PCB_A.

So I'd like to suggest that you can refer to the thread as below to figure out the reason that trigger the hard fault at first.

http://mcuoneclipse.com/2012/11/24/debugging-hard-faults-on-arm-cortex-m/
Have a great day,
Ping

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

0 Kudos
Reply
14,554 Views
yuriydovgalyuk
Contributor III

Hi jeremyzhou,

Thanks for trying to help me!

I also forgot to mention, that from time to time it is possible to make the windows to detect a CDC device, and it is listed in Device Manager. However, after few seconds later the hart fault happens and the device stops working. So, here I am in doubt about USB data lines are the problem... Would it help if I post a complete PCB layout of the board that is faulty? If so, you can find it attached.

Actually, I was trying to find a reason for hard faults, but what I found out is that the places where errors happen are random. Meaning that it is not in defined place I have the fault, they change very often.

Additionally, I found out that that was a bus/usage fault propagated to hard fault, when I switch to trigger explicit bus or usage fault, I get bus fault more often than usage fault. Very often I got the problem arise in mutex release fuction (i use FreeRTOS). Sometimes other places. Sometimes the error is unaligned memory accesses, sometimes undefined instruction, sometimes other type....

And this only happens when USB is connected to socket.

Could it be that I get some strange data via USB and these data are interpreted incorrectly and then code behaves strange causing faults? Or maybe (now my fanstasy works) incorrect electrical signal from USB corrupts the MCU ram memory data?

I also noticed that if I put brakepoint in the place where BDT is initialized/cleared and simply run directly after the debugger stopped, then I will not get faults and application will run (but USB would not work because timings are wrong).

What I also was thinking of, is there a change that other pins, not directly involved in USB connection may have such a side-effect on MCU? The PCB is router to support more different chips, but they are not soldered yet.

The last thing I would like to add is that the MCU I use on PCB_A is newer than on PCB_B. Could it be different MCU versions, where older can run the code and newer cannot. Old one comes from around jun 2014 and newer from oct 2014.

0 Kudos
Reply
14,554 Views
jeremyzhou
NXP Employee
NXP Employee

Hi Yuriy Dovgalyuk,

The most important thing for us is how to locate the error now.

I've attached Kinetis peripheral module quick reference and you can refer to the USB circuit design from the 14.6 Hardware implementation in this Doc.

I'd like to suggest that you can use USB protocol analyzer to capture the data of the communication between the PC and target, I think it will helps to seek out the error that still bother you until now.

Have a great day,

Ping

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

0 Kudos
Reply
14,554 Views
yuriydovgalyuk
Contributor III

Hi

I get USB logs using wireshark. See attached. Hope this can show something.

After few moments the MCU jumps into hard fault and everything hangs.

BR,

Yuriy.

0 Kudos
Reply
14,554 Views
jeremyzhou
NXP Employee
NXP Employee

Hi Yuriy Dovgalyuk,

I've had a look through the attachments. According to the attachment, when use a USB cable integrate the PCB A with the PC will trigger PC send the Clear_feature request to the target (Fig 1),

then the MCU seems like to sink in a black hole and it will break down , in another word, MCU will become exhausted when it strive to make the enumeration pass after the PC send the Clear_feature request.

I've shared a paragraph about the Clear_feature request and please check it.

2015-01-22_16-30-30.jpg

                                                                              Fig 1

2015-01-22_16-57-01.jpg

                                                                           Fig 2
Have a great day,
Ping

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

0 Kudos
Reply
14,553 Views
yuriydovgalyuk
Contributor III

Hi jeremyzhou,

Thanks for investigating the files.

So, you would suggest to debug in this function? Or...? Maybe I do not understand completely your point, but as I can see from logs MCU responds with SUCCESS to the CLEAR_FEATURE request.

Do you see more here?

In the usb_framework.c ( USB_Strd_Req_Feature function ) I found the following:

        else

        {

            /* TODO */

            /* if the feature is 0, a request error need to be sent out*/

          

        }

Could it be an issue?

I also attached file for the PCB B that runs fine.

BR, Yuriy.

0 Kudos
Reply
14,554 Views
danielrosales
Contributor I

Hi Yuriy!

Have you solved the issue??

0 Kudos
Reply
14,554 Views
yuriydovgalyuk
Contributor III

Hi Daniel,

Nope, I just gave up. I use another board, which works fine with USB.

Have one more board to test, but have to solder all stuff first.

0 Kudos
Reply
14,554 Views
jeremyzhou
NXP Employee
NXP Employee

Hi Yuriy Dovgalyuk,

I've been looking for the differences of the enumeration between the PCB A and PCB B for two hours.

The only difference is the host would send the clear feature to disable the Device_remote_wakeup function when PCB A enumerated, however it don't exist when the PCB B enumerated.

So I consider the the request break down the connection between the PC and PCB A.

But I've also not seek out the precise the error with the PCB A based on the screenshot you shared then would cause this issue until now.

From your previous replies, I had learned that the MCU used is not same between the PCB A and PCB B.

I'd like to suggest that you should  focus on the hardware difference between the PCB A and PCB B especially about the solder at first, then you can try use the older MCU from the PCB B instead of the newer one on the PCB A.
Have a great day,
Ping

2015-01-26_14-56-59.jpg

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

0 Kudos
Reply