How to disable BC 1.2 on RT1050

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

How to disable BC 1.2 on RT1050

7,802 Views
eric_yp_chen
Contributor I

Hi @jeremyzhou 

I've got a problem during the USB 2.0 certification.

Our product works in device only. It is just like a USB camera.

But an instrument shows our device support BC 1.2 (Battery Chart 1.2 Standard) while testing the electrical item.

It shouldn't support it cause our device do not have a battery inside.

I'd like to know how to force USB PHY not responding this BC 1.2 protocol ?   

 

Eric

Labels (1)
0 Kudos
14 Replies

7,785 Views
jeremyzhou
NXP Employee
NXP Employee

Hi,

Thank you for your interest in NXP Semiconductor products and for the opportunity to serve you.
1) I'd like to know how to force USB PHY not responding this BC 1.2 protocol ?
-- Maybe you can try to disable the charger detection feature via configuring the bits as the below figure shows.

2021-01-18_15-10-00.png
Have a great day,
TIC

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

 

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

0 Kudos

7,775 Views
eric_yp_chen
Contributor I

Hi @jeremyzhou 

{CHK_CHRG_B, EN_B} already been set to {1,1} in my source code, which I modified from example of "RT1050_CDC_VCOM_BM".

eric_yp_chen_0-1611277831600.png

Any possible solutions ?

Best Regards,

Eric

 

 

0 Kudos

7,754 Views
jeremyzhou
NXP Employee
NXP Employee

Hi,
Thanks for your reply.
It seems a bit weird and I think I need to contact the AE team later.
So I was wondering if you can describe your question in detail again, it can help the AE team's USB expert to figure the issue out quickly.
Looking forward to your reply.
Have a great day,
TIC

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

 

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

 

 

 

 

Have a great day,
TIC

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

 

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

 

0 Kudos

7,750 Views
eric_yp_chen
Contributor I

Hi @jeremyzhou 

Question as below:

We're design a USB camera with RT1052.

This USB camera works only in device mode and no battery inside.

We want to make sure that this device "do not support BC 1.2".

That means this device don't have to detect charger.

 

But we found that even we had change {EN_B,CHK_CHRG_B} to {1,1} during USB initialization.

RT1052's USB PHY does not do what we want.

Instead, the charger detection protocol already done before initialization in firmware.

I did measure the USB_DP/DM waveform as below.

Red arrow represents the same time when I plug our device into a host.

Blue arrow represents when the DCDC_3V3 had setup ready.

Which means USB PHY already do charger detection before firmware boot properly.

eric_yp_chen_0-1611307475793.png

 

This is not acceptable while qualifying the device which is specified not supporting BC 1.2

 

Thank you

Eric

0 Kudos

7,736 Views
jeremyzhou
NXP Employee
NXP Employee

Hi,

I get a reply from the AE team today and I was wondering if you can answer their questions.

Is the customer using our SDK? Did they use a particular device example as a starting point? I'm looking at the code, and I don't see anywhere that the SDK would set the USBn_CHRG_DETECT[EN_B] bit to disable the charge detector.

So where did they add the code to set this bit? Seems like they set it too late. It looks like the USB_EhciPhyInit function in usb_phy.c would be the place add the code that sets EN_B. Is this what they did? 

Another thing that might be a factor is how they are powering the device. Is the camera powered from the USB VBUS, so that the part can't start up until the USB cable is plugged in? If so, it might be difficult to disable the charge detect fast enough. If that is the case, then they might need to put the charge detect disable into the CLOCK_EnableUSBhs0PhyPllClock() or CLOCK_EnableUSBhs1PhyPllClock() functions (depending on which USB module they use). 

Have a great day,
TIC

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

 

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

0 Kudos

7,724 Views
eric_yp_chen
Contributor I

Hi @jeremyzhou 

Our SDK version is 2.6.5 

Also , I've done verification on NXP's RT1050-EVK.

It shown same issue during verify BC1.2

The waveform shown USB D+ rise as USB_VBUS.

It is not possible to turn off this behavior through any register setting during bootup. (Cause DCDC_3V3 is not ready.)

I guess USB_PHY already powered by USB_VBUS pin. 

If there's no other fuse or OTP register setting which could disable this behavior.

The possible solution might be delay the connection between USB5V from connector to VBUS pin.

Please help to confirm this solution form NXP's AE.

It is a major issue that holding us not to move stage into mass production.

eric_yp_chen_0-1611818317896.png

 

Best Regards,

Eric

 

 

 

0 Kudos

7,697 Views
jeremyzhou
NXP Employee
NXP Employee

Hi,

AE team has done some testing, however, he doesn't capture anything that looks like a charge detect cycle, and below it's the integral reply.
I've been running some tests here. Unfortunately I'm having a hard time getting clean scope shots. It turns out that USB_EhciPhyInit() does disable the charge detect feature. I'm running the dev_hid_mouse_bm example from the SDK. I'm seeing a steady ramp on D+. This is expected behavior as there is a pullup on the D+ line for device mode. I'm not capturing anything that looks like a charge detect cycle, and don't expect to as the feature is disabled.
In my case, I'm powering the board from the on-board debug connector (default board config). So I've got the code executing, USB_EhciPhyInit() has run, and I can verify using the debugger that EN_B has been cleared all before I plug in the USB cable for the USB1 port. If you try to power from the USB1 port (bus powered device scenario) or leave the cable plugged in continuously, then that does potentially change things as USB_EhciPhyInit() might not be disabling the charge detect early enough.

Have a great day,tek00005.png
TIC

 

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

 

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

0 Kudos

7,650 Views
eric_yp_chen
Contributor I

Hi @jeremyzhou 

In our case, we cannot power the rt1050 by any debug port.

We've tried two solution to pass the BC 1.2 verification but failed

Solution 1: 

Spec of BC1.2 shows to prove that device support BC1.2, device need raise USB D+ at least 40 ms and wait a CDP response on USB D- .

As we known the USB D+ of RT1050 will automatically raise to "0.6V" when OTG1_VBUS is powered.

So we modified the power sequence for "not match" the spec, in other hand , make RT1050 boot as fast as possible to ensure that USB D+ will not raise over 40 ms.

However it still not pass. (Spec & Waveform as below)

eric_yp_chen_0-1614759982080.png

scope_18.png

Solution 2: 

We took AE's suggestion , powered the OTG1_VBUS after MCU boot completed.

But we still get this phenomena. USB D+ rise about 100 us.

The yellow waveform is measured from USB host VBUS and OTG1_VBUS is not even powered.

eric_yp_chen_1-1614760330002.png

 

Anyway , both of these two solution failed.

Also the certification company is Allion from Taiwan.

The equipment the used in our certification is MQP USB-PET Compliance Tester.

eric_yp_chen_2-1614760563985.png

And I've upload the test log , you could find it at attachment.

Log shows our device still implemented BC1.2.

It should display like this " BC 1.2 has not be implemented."

eric_yp_chen_3-1614760702677.png 

Please give us further suggestion.

 

 

0 Kudos

7,597 Views
jeremyzhou
NXP Employee
NXP Employee

Hi,

Thanks for your reply and I was wondering if you can clarify the below inquires.
1) According to your introduction, the spec of BC1.2 shows to prove that the device support BC1.2, the device needs to raise USB D+ at least 40 ms and wait for a CDP response on USB D-, however, the below figure seems doesn't conform to above the rule. Please explain it again.

jeremyzhou_0-1614927605362.png

 


2) The yellow waveform is measured from USB host VBUS and OTG1_VBUS is not even powered.,
Can you explain the above test condition, as it's a bit confusing?

jeremyzhou_1-1614927627094.png

TIC

 

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

 

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

0 Kudos

7,580 Views
eric_yp_chen
Contributor I

Hi @jeremyzhou 

(1) In order to "not match " BC 1.2 spec, we tried to reduce boot time.

     Make sure the USB_D+ not rise over 40ms. (We guess the BC1.2 tester will check rise time as spec)

    However , the it only check USB_DP voltage after VBUS is connected.

    To pass the certification, USB_DP voltage must rise larger than 2000mV(Direct into Enumerate State) or lower than 200mV before enumeration, otherwise it won't pass the test.

    

eric_yp_chen_0-1615271618808.png

This is the test log reported from the tester.

eric_yp_chen_1-1615271854583.png

 

We want the USB_DP signal ack like this.

Clean and not even rise a little bit before enumeration.

eric_yp_chen_2-1615272120550.png

 

 

BR,

Eric

 

 

 

 

 

0 Kudos

7,503 Views
jeremyzhou
NXP Employee
NXP Employee

Hi,
Sorry for the reply late.
In basic, I've already replicated the phenomenon you mentioned, after plugging the USB cable, the USB_D+ will rise to 560 mv and it keeps the status for about 18.2 ms, based on this wave of USB_D+, we can figure out that charger detection process definitely happens prior to the enumeration.
I'll contact the AE team soon about the phenomenon and give a reply ASAP.

Yellow: VBUS-5V, Red: DP, Green: DN

tek00023.pngtek00024.png
TIC

 

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

 

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

0 Kudos

7,549 Views
jeremyzhou
NXP Employee
NXP Employee

Hi,

Sorry for the reply late, I was wondering if you can share the schematic of your board, especially the power supply and USB port portions.

Have a great day,
TIC

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

 

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

0 Kudos

7,544 Views
eric_yp_chen
Contributor I

Hi @jeremyzhou 

I'm afraid we could not share with you , schematic file is company's confidential property.

But I'm sure it's same as NXP's RT1050-EVK.

 

Modification as below :

OTG1_VBUS is directly connected to VBUS from USB connector.

eric_yp_chen_0-1615470654292.png

eric_yp_chen_1-1615470872387.png

 

 

 

0 Kudos

7,467 Views
jeremyzhou
NXP Employee
NXP Employee

Hi,
The AE team shares the below advice to disable the battery charge function on the device board, please give it a try.
1. Need to guarantee no other voltage to drive the VBUS line.
2. Device is working in self-power mode.
3. A 2.2uF capacitor on the VBUS line is a must.
Have a great day,
TIC

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

 

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

0 Kudos