CYUSB3064 Silicon is backfeeding VDDIO1 or VDDIO2 supply

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
ScGr_289066
Level 5
Level 5
100 replies posted 50 replies posted 25 replies posted

Hi All,

I believe we are experiencing a Silicon design problem with the CYUSB3064 chip.  This is the second generation of the design.  We noticed the same issue on the 1st generation, but never got to the bottom of it.  This design appears to be worse (e.g. more leakage).

We have a CX3 design that runs VDDIO1 & VDDIO2 from 1.8V, VDDIO3, CVDDQ from 3.3 volts, TXVDD/RXVDD, AVDD, MIPI_VDD and VDD from 1.2V.  The board contains four voltage regulators powered by USB's VBUS (5V) whose outputs are: 1.2, 1.8, 2.5 and 3.3V.  All the regulator outputs are nominally correct except the 1.8V regulator is 2.7V and appears to be back-fed.  The 1st generation boards supply was around 2.1 volts.

With all the components except the CX3 removed from the 2nd generation PCBA, including the 1.8V regulator, the 1.8V supply still sits at about 2.7V.  If I connect an ammeter between the 1.8V supply and ground, I measure 15.7 mA, so this is not a dead-short.  After removing the CX3 the 1.8V measures zero.

Are we misusing the CX3 in some manner to explain this leakage current?

Thanks,

Scott

0 Likes
1 Solution

Hi Yashwant,

So to summarize: you found that over driving CLKIN (to 3.3V) causes the CX3 to back-feed the 1.8V supply.  A very reasonable conclusion.  My similar experiment didn't find that result but it's possible my experiment was somehow flawed or that leakage path is chip lot dependent.  I don't know that my experiment was flawed, but it could have been.  I could repeat this experiment on a fresh board, but am not sure it is worth the effort: see below.

My experiment on the e-con board moved the 0 ohm R82 resistor to position R91, so VCCIO was driven by their on-board 1.8V regulator (LT3503) which can only source current not sink it.  So, had there been a reverse feeding issue the 1.8V node would rise above 1.8. When you pointed out that all the VDDIO pins were being driven at 1.8, I lifted L2 and wired its source end to 3.3V so that VCCIO_CLK runs at 3.3V.  I did not observe any back-feeding in this configuration.

I did the oscillator experiment on one of our boards by itself, so yes, the accelerometer was still present on the board as were all the other components on the 1.8V supply.

I should mention that this is becoming somewhat of an unimportant issue (from our perspective).  Our interaction has been informative, but is taking way too long in light of our customer commitments.  We have redesigned our boards (several weeks ago) to run all the IO voltages at 3.3V which is the only sure way to avoid this problem.

Best,

Scott

View solution in original post

0 Likes
23 Replies
YashwantK_46
Moderator
Moderator
Moderator
100 solutions authored 50 solutions authored 50 likes received

Hi Scott,

Can you please share the schematics of your board so that we can get a better understanding as to what could be going wrong in your design?


Also, without any component on board, except the regulator, can you please check the voltage and if there's any leakage current then also?

Regards,

Yashwant

0 Likes

Hi Yashwant,

I forgot to mention several key details.

First, nothing is attached to any of the connectors except the USB connector for power.  With all the parts on the board, the 1.8V supply sits at nearly 2.7V on several boards.  This caught my attention because the boot flash is only rated for 1.9V.  The CX3 enumerates on USB correctly, and I can load its firmware into RAM or SPI Flash using Control Center.  With code loaded, the CX3 fails to initialize the I2C bus with error 0x55 (see case 210047).

Yesterday, I experimented with one of the boards trying to locate the source of leakage current by removing key components one-at-a-time until the leakage disappeared.  Here's what I did.  I first removed the 1.8V regulator, VR6.  The 1.8V node remained at 2.7V.  I then removed, in this order: U2, U6, M3, R8 & R16.  At this point nothing had changed, the 1.8V node was still sitting at 2.7V.  I then connected an ammeter between 1.8V and ground.  I measured 15.7 mA.

Finally with no other components connected to 1.8, I removed the CX3 (U8).  The 1.8V node dropped to zero.  Then I replaced VR6, per your request today.  The 1.8V node now measures 1.8V (for the first time on this board).

Best,

Scott

0 Likes

Hi Scott,

Did you follow the schematics of the CX3 RDK by e-con systems? If not, please go to this website and download the schematics and the hardware design guidelines for CX3.

Can you power the board with all the components along with CX3 and check the GPIO's in the VDDIO1 and VDDIO2 power domain from the CX3 datasheet and check which of them are high when you are measuring 2.7V on the 1.8V line?

Some of the problems that i found are:

1.) In the schematics, J2- Type-C Receptacle( or is it plug?? ) is connected in a wrong way. The SSTXM, SSTXP of CX3 should be connected to TX-, TX+ of the connector and same goes for RX- and RX+.

2.) Is CX3 enumerating as a 2.0 or a 3.0 device?

3.) Why are PG's of all the regulators connected to a single 10K resistor instead of connected individual PG's of regulators to their respective OUT's ?

4.) The reset switch SW1 needs to be pulled up using a suitable resistor to 1.8V, or else, if SW1 is pressed, it will cause the PG of VR3 to provide a low-impedence path and will make the 1.2V regulator to ground ( since 1.2V is less than 1.8V at PG).

5.) Why are you using higher capcitance for AVDD, VBUS instead of the recommended values (Is there any specific reason) ?

Regards,

Yashwant

0 Likes

Hi Yashwant,

I'll address your "problems" first.

1&2) We are using a receptacle.  It works, the PC communicates with the CX3 as a USB3 device.  It is sensitive to which direction the connector is plugged, but please stick to the leakage issue.

3) The PG outputs are open-collector and are wire-ORed to the CX3 reset pin.  This holds the CX3 in reset if *any* of the regulators are not operating correctly.  The CX3's RESET input is powered by 1.8V, hence these open-collector signals are pulled-up by R30 to 1.8V.

4) I'm afraid you have misinterpreted the design.  The reset switch is pulled-up through R30 a 10K resistor to 1.8V  Closing the reset switch does indeed pull all the PG open-collector outputs to ground, but doing so has no effect on any of the four regulator outputs.  I suggest you read TI's TPS74801 data sheet to find out how these regulator's operate.

5) There is second board that attaches to this board.  This board draws a substantial amount of extra current, hence the additional filtering.  As I said in the original post, we have not connected the second board because of this leakage issue.

I did refer to e-CON's documentation.  The reason they are not seeing this leakage problem is because they run VDDIO1 and VDDIO2 at the same voltage level as VDDIO3 and CVDDQ, namely 3.3V.

I am postulating that there is a leakage path through the CX3 from VDDIO3 or CVDDQ to VDDIO1 or VDDIO2.  Since we have VDDIO1 and VDDIO2 tied together, we can't know if the leakage affects one or both of these supplies.  e-CON's design would not have this issue because they run all these supplies at the same potential.

Are you saying the CX3 does not meet it's specifications which says these supplies can run from 1.8, 2.5 or 3.3 and the only successful way to use it is to connect all these supplies to 3.3?

To directly answer your earlier question: SDA, SCL are both pulled to the 1.8V supply which is being back-fed by the CX3 to 2.7V.  Similarly, DBG_TX is also at 2.7.  The 1.8V supply *always* measures 2.7V even before the CX3's firmware is loaded, it does not changed after firmware is loaded.

Thanks,

Scott

0 Likes

Hi Yashwant,

Here's an update.  Your comments about USB is correct.  The device is enumerating, but not as a super speed device.  It communicates, but will not stream video even though the sensor is streaming to the CX3 and the CX3 appears to be receiving the video correctly (HSYNC/VSYNC test points appear correct).

I now understand your USB connection comment, I've reversed the pairs.  I thought you meant I'd reversed the "1" and "2" sides (which was intentional).

This board also has problems initializing its I2C interface (a block error 0x55 is reported).  I have a case for this: https://community.cypress.com/message/210346?et=watches.email.thread#210346

The experiment we did was to connect the 1.8V supply to 3.3V.  All the parts on 1.8V are 3.3V compliant, so running everything at 3.3V is OK.  After doing this, the I2C problem is gone (I2C initializes OK), so this is perhaps another symptom of the CX3's leakage issue.

However, none of this changes the fact that the CX3 leaks to VDDIO1/2 is they are connected to a lower potential than VDDIO3/CVDDQ.

Thanks,

Scott

0 Likes

Hi All,

Has anyone been able to reproduce this?

Scott

0 Likes

Hi Scott,

Sorry for being late but i am still trying to figure out as to what is going wrong.

One main thing that i can point out is that the eCon CX3 RDK uses a different type of regualator for 1.8V than compared to the regulator that is used for all the other power domains ( 1.2V, 2.5V, 3.3V). If you can refer to the schematics of the RDK board, you can notice it.

I am trying to get a hold of the exact reason as to why that's being done in the RDK.

Will update you as soon as I figure it out.

I had a question about one of your comments,

>>The experiment we did was to connect the 1.8V supply to 3.3V.  All the parts on 1.8V are 3.3V compliant, so running everything at 3.3V is      OK.  After doing this, the I2C problem is gone (I2C initializes OK), so this is perhaps another symptom of the CX3's leakage issue.

-->So, after doing this, did you still find the 1.8V at 2.7V? or was it at 1.8V?

Regards,

Yashwant

0 Likes

Hi Yashwant,

After connecting the 1.8V and 3.3V supplies they all sit at 3.3.

Best,

Scott

0 Likes

Hi Yashwant,

I'm not sure the RDK using a different type of 1.8V regulator is significant since 1.8V isn't connected to the CX3.  All it's IO runs at 3.3.

Best,

Scott

0 Likes

Hi Scott,

If possible, can you please share the layout of your board as well?

And share if you have any update on your side.


Regards,

Yashwant

0 Likes

Hi Yashwant,

If you provide me with a private email address I can share the layout.  The design is a commercial product I cannot post it to a public forum.

Best,

Scott

0 Likes

Hi Scott,

Private message has been received and i will get back to you with results shortly.


Regards,Yashwant

0 Likes

Hi Scott,

Can you please take off the accelerometer U6 ( MMA8652FC) from your board or remove the power connection for the part and then check if you still face the same issue?

I suspect that accelerometer may be the part that's causing the leakage issue as we had seen some issues in the past where an accelerometer was the cause of finding some back-feeding issues in customer boards?

Please keep all the components on the board intact and only remove the power to U6 and then measure the 1.8V volt power domain.

Please get back to us with the findings.


Regards,
Yashwant

0 Likes

Hi Yashwant,

Sorry you missed my September 24'th post.  I did exactly this,

removed components one-at-a-time and monitored the effect on the

1.8V supply starting with the 1.8V regulator.  The second component

I removed was the accelerometer.  It is not the source of

leakage.  I removed all components from the 1.8V supply until all

that remained was the CX3.  The 1.8V supply node was still raised to

2.7V.  In spite of removing all the other components, the 1.8V node

had not dropped in potential until I removed the CX3.

Before removing the CX3, I placed an ammeter across 1.8 and ground

and measured 15.7 mA leaking through the CX3.

Best,

Scott

0 Likes

Hi Scott,

I have taken a e-con systems CX3 RDK device and tried to implement the same application as your design.

I have powered the VDDIO1 and VDDIO2 power domains with 1.8V ( removed the R82 resistor and just powered the VCCIO power domain using a 1.8V power supply).

And powered the CVDDQ power domain with a 3.3V ( removed L2 inductor and gave the VCCIO_CLK with a 3.3V external power supply).

I am attaching a picture of the findings along with the post.


The 1.8V node was sitting at 1.8 V and only 7-8mA of current was being drawn from the supply.

No Back-feeding was seen as such when reproducing the issue.

The issue is related to the board design and not the CX3 IC for sure.


Regards,

Yashwant

CX3_no_backfeed_results.jpg

0 Likes

Hi Yashwant,

I'm not sure your test is valid because your bench supply can both source current *and* *sink* current.  If the bench supply were sinking current I don't know if the meter would read negative?  Can you add a small sampling resistor in series with the bench supply and measure the voltage across it to confirm whether your bench supply is *sourcing* current or *sinking* it?

Thanks for your help.

Best,

Scott

0 Likes

Hi Scott,


I think the test is valid because i have previously set a current limit of 200mA and the voltage of 1.8V and 3.3V in both the supplies and all they were drawing was only 7mA and 2mA only.

I tried again with the current limit set to 10mA and still the result was same.

I am saying that the test is valid because, if there was more current draw than the limit specified, the voltage would drop instantly as the supply would enter CC mode but we were not able to see anything like that.

If you think that we can do something to have a more relevant test, you can suggest.

Regards,
Yashwant

0 Likes

Hi Yashwant,

I'm not sure that your test isn't confirming there there is leakage issue because you don't know for sure that the current the bench supply is showing, 7 mA, isn't feeding into the 1.8V supply.  An ammeter or sampling resistor will confirm the current is being supplied rather than flowing into the supply.  Supply current limits typically only limit current magnitude from the supply, not that current's direction, so I am suspicious that the 7 mA is flowing *into* the 1.8V supply.

Best,

Scott

0 Likes

Hi Yashwant,

I repeated your test on the same model c-con Systems board we have here.  I moved R82 to the R91 position, which uses their on-board 1.8V regulator to power VDDIO1 & VDDIO2 instead of their on-board 3.3V regulator.  The 1.8V on-board supply measured 1.8V in this configuration, and was supplying about 3.3 mA to the CX3's VDDIO1/2 pins.  This does not indicate any sort of problem.  Although I would still like you to confirm that the 7 mA in your experiment is flowing out of your 1.8V supply into the CX3 and not from the CX3 into your power supply.

This finding leads me to believe the leakage may be batch related.  I have the CX3 chip that I pulled from our board, and several other boards that exhibit the leakage issue.  Would they be of any use to you to get to the bottom of the issue?  I will attach a photo of the failed chip, and one from the e-Con Systems board (that doesn't show the leakage issue).

e-con CX3.jpg

Optel CX3.JPG

The top photo is the e-con board, the lower image is the removed chip from our board.

Thanks for your continuing support.

Best,

Scott

0 Likes

Hey Scott,

Can you please tell how many boards do you have which exhibit this behavior and how many of them don't?

Also, one thing to note in the experiment you performed by moving R82 to R91 is, you are now running VCCIO at 1.8V (VDDIO1 and VDDIO2) and also the VCCIO_CLK (which is derived from VCCIO) powering the CVDDQ at 1.8V as well.

So, now all of VDDIO1/2 and CVDDQ are at the same potential and that's the reason why you didn't notice the issue.

To address the issue of backfeeding, i double-checked the power domains and found that you remarks about the back-feeding were correct.

The CX3 is being back-fed by the MIPI bridge as both are being given clock from the same oscillator which is powered by 3.3V.


The suggestion that i could give now, is to run the oscillator in your design at the potential corresponding to the lowest power domain voltage (1.8V in your case) while maintaining the 19.2MHz clock frequency and run both the REFCLK and CLKIN at 1.8V to maintain the same potential between the two.


Can you please implement the same and revert back to us with the findings?

Regards,

Yashwant

0 Likes

Hi Yashwant,

All the boards of our latest batch show the leakage issue, all 10 of them.

As far as the 19.2 MHz oscillator driving the two different power domains at 3.3V. I noticed this very early during troubleshooting and rewired one of our boards to operate the 74LVC2G17 buffer (U5) on the 1.8V supply, then used it's output to drive only REFCLK on the VDDIO1 domain.  I routed the clock directly from the oscillator to CLKIN which operates on the CVVDQ domain (3.3V).  This had no effect on the back-feeding.  The 1.8V regulator was still pulled up to 2.7.  I don't believe this is the cause of back-feeding, although it clearly is a design issue.

I reviewed your comments on my experiment on the e-con Systems board and understand your point.  I've gone back and lifted the VCCIO end of L2 and wired it to 3.3V.  Since doing that the 1.8V regulator on the e-con board sits at 1.8, so I still don't see any sign of back-feeding on this board.

Best regards,

Scott

0 Likes

Hi Scott,

I tried doing the process that you did with the regulator as follows on the e-con systems CX3 RDK board in the following steps:

1.) Replaced R72 with R74 with 22 Ohm resistor bypassing the buffer.

2.) De-soldered the buffer U8 from the board and pulled up PIN 5 of the IC to power it seperately via an external power supply and supplied it with 1.8V external supply.

3.) So, now the buffer is at 1.8V and the oscillator is supplied with VCCIO_CLK at 3.3V.

Findings:

-> There's no backfeeding issue with the VDDIO domain now which was at 2.7V previously when the REFCLK and CLKIN is supplied with 3.3V now reads 1.8V only.

-> Didn't connect the VDDIO 1/2 with any power and found that it was at 1.8V only and not back-fed.

Also, in your experiment with the e-con systems CX3, were you powering the VCCIO to 1.8V by an external supply while you were measuring or was it left open when you were checking for the voltage?

In the board where you rewired the oscillator, does it still has the accelerometer (U6) attached to the board or is U6 removed from the board at the time of testing?

Regards,

Yashwant

0 Likes

Hi Yashwant,

So to summarize: you found that over driving CLKIN (to 3.3V) causes the CX3 to back-feed the 1.8V supply.  A very reasonable conclusion.  My similar experiment didn't find that result but it's possible my experiment was somehow flawed or that leakage path is chip lot dependent.  I don't know that my experiment was flawed, but it could have been.  I could repeat this experiment on a fresh board, but am not sure it is worth the effort: see below.

My experiment on the e-con board moved the 0 ohm R82 resistor to position R91, so VCCIO was driven by their on-board 1.8V regulator (LT3503) which can only source current not sink it.  So, had there been a reverse feeding issue the 1.8V node would rise above 1.8. When you pointed out that all the VDDIO pins were being driven at 1.8, I lifted L2 and wired its source end to 3.3V so that VCCIO_CLK runs at 3.3V.  I did not observe any back-feeding in this configuration.

I did the oscillator experiment on one of our boards by itself, so yes, the accelerometer was still present on the board as were all the other components on the 1.8V supply.

I should mention that this is becoming somewhat of an unimportant issue (from our perspective).  Our interaction has been informative, but is taking way too long in light of our customer commitments.  We have redesigned our boards (several weeks ago) to run all the IO voltages at 3.3V which is the only sure way to avoid this problem.

Best,

Scott

0 Likes