XCORE-200 VBUS

Technical discussions around xCORE processors (e.g. General Purpose (L/G), xCORE-USB, xCORE-Analog, xCORE-XA).
User avatar
ccrome
Active Member
Posts: 44
Joined: Wed Sep 23, 2015 1:15 am

XCORE-200 VBUS

Postby ccrome » Fri Feb 10, 2017 7:33 pm

Hi there,
I see that USB VBUS is supposed to be directly connected to the USB_VBUS pin of XU216-512-TQ128, correct?

Since the VBUS will be almost instantly 5V, well before the 3.3V and 1.0V voltage rails are stable, is there a problem here? can USB_VBUS be 5V when VDD and VDDIO are 0V?

Where is the spec for for that?

Thanks,
-Caleb
User avatar
mon2
XCore Expert
Posts: 743
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Postby mon2 » Fri Feb 10, 2017 11:34 pm

Hey Caleb. Do you have power sequencing circuits to monitor each power rail ? Can you post your schematic for the relevant power supply ? Also saw your other post.

Is the USB interface damage permanent ? Do you have ESD protection for the USB interface ? Power sequencing should be the first area of review and ESD protection would not hurt if it is missing. Does the USB interface die on its own or during a docking event to a host PC ?

There are some freeware USB monitor tools that can offer an insight to which packets or lack of are being sent by the XMOS CPU.
User avatar
ccrome
Active Member
Posts: 44
Joined: Wed Sep 23, 2015 1:15 am

Postby ccrome » Sat Feb 11, 2017 12:14 am

mon2 wrote:Hey Caleb. Do you have power sequencing circuits to monitor each power rail ?

No, my power sequencer simply waits about 15mS for each stage (15mS to bring up 1.0V, 15mS to release POR. I verified with a scope, that the power sequence does happen in what seems a totally reasonable fashion.

mon2 wrote:Can you post your schematic for the relevant power supply ?

Yes, attached.
Image
Image

So, perhaps it was a mistake to use a simple delay chip, rather than a voltage monitor. But watching the actual voltages rise, everything looks okay, except that it takes longer than 10ms from VDDIO = 3.3V to the start of VDD_CORE rising, which I don't know if that's a problem or not.

mon2 wrote:Also saw your other post.

Is the USB interface damage permanent ?

Yes, it's permanent.

mon2 wrote:Do you have ESD protection for the USB interface ?

No. I copied the x-core 200 multi channel reference design, which had a USB switch. I removed the switch, but did not add a protection circuit in its place.

mon2 wrote:Power sequencing should be the first area of review and ESD protection would not hurt if it is missing. Does the USB interface die on its own or during a docking event to a host PC ?

I was able to retrofit some TVS diodes onto the D+ and D- lines, but still had the same problem.

mon2 wrote:There are some freeware USB monitor tools that can offer an insight to which packets or lack of are being sent by the XMOS CPU.

Do you have a link to your favorite?


Thanks!

-Caleb
User avatar
ccrome
Active Member
Posts: 44
Joined: Wed Sep 23, 2015 1:15 am

Postby ccrome » Sat Feb 11, 2017 12:34 am

And here are the power rails coming up. From top to bottom: 5V5 (VBUS), 3V3 (VDDIO), 1V0 (VDD), RST_N

Image
User avatar
mon2
XCore Expert
Posts: 743
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Postby mon2 » Sat Feb 11, 2017 6:37 am

Assuming that assembly of the PCB and XMOS CPU mounting (including the metal belly) is not the issue.

The power up timing is a deja-vu discussion and found the comments from Redeye:

viewtopic.php?f=26&t=3450&hilit=redeye&start=20

norman wrote:
what is your appreciation of "very quickly " for "1v0 doesn't come up very quickly after the 3v3" ? thanks


Redeye wrote:
Well, 100ms is too much from our experiments. The testing wasn't exhaustive because this wasn't the problem we were looking for, but it seems to need to be no more than a few milliseconds.


Perhaps a good idea to wait from XMOS staff on the power sequencing but this looks to be the root cause. Does the damage occur during a fresh docking of the USB port to a PC ?

While you may be able to alter the delay times between power rails to tweak a working permutation, the risk is too high to damage future replaced XMOS CPUs. Consider to fix the root issue and in the process, alter the power supplies to reduce your BOM costs. Place the required voltage monitor circuits (3v3 first -> then 1v0 after 3v3 deemed to be stable) and then release the reset line. The change in the BOM can justify the re-spin and pay for the next batch of boards. When ready, post your fresh schematic for a final review.

Do insert ESD protection devices into the circuit; consider to add USB EMI filter inline with the USB interface. ESD protection = Socay is quality and low cost. EMI filter = Kingcore (Taiwan) but you can start with using Bourns or Littlefuse with the same footprint but for a cost reduction, move to the offshore suppliers.

Have a review of the Diodes Inc. AP3402 DC-DC switching power supply and mate this with the Taiyo Yuden NR6020T shielded inductor.

http://www.digikey.com/products/en/indu ... ageSize=25

http://www.digikey.com/product-detail/e ... ND/5359840

http://www.mouser.com/ProductDetail/Dio ... b1cFR9iQ==

https://products.avnet.com/shop/en/ema/ ... ryfeed_VSE
henk
Respected Member
Posts: 346
Joined: Wed Jan 27, 2016 5:21 pm

Postby henk » Mon Feb 13, 2017 9:20 am

Hi Caleb,

The USB_VBUS pin is only used to monitor the presence of VBUS in software - so it does not matter when it comes up, as long as it comes up before the software is up and running.

The new datasheets have more guidance on how to connect VBUS, with extra information on how to avoid any inductive swing in VBUS reaching the chip. In short: don't connect it if it is bus-powered, and use a series resistor if powered from a separate supply.

Cheers,
Henk
dweeb4
Active Member
Posts: 45
Joined: Mon Jan 19, 2015 12:47 pm

Postby dweeb4 » Mon Feb 13, 2017 2:46 pm

I don't wish to drag this OT but can you say where in the software that Vbus is referenced?
I'd like to investigate the possibility of avoiding the need for this Vbus sensing - some other USB receivers on other chips (ARM) don't appear to need Vbus sensing
Last edited by dweeb4 on Mon Feb 13, 2017 11:16 pm, edited 1 time in total.
User avatar
ccrome
Active Member
Posts: 44
Joined: Wed Sep 23, 2015 1:15 am

Postby ccrome » Mon Feb 13, 2017 10:37 pm

henk wrote:Hi Caleb,

The USB_VBUS pin is only used to monitor the presence of VBUS in software - so it does not matter when it comes up, as long as it comes up before the software is up and running.

The new datasheets have more guidance on how to connect VBUS, with extra information on how to avoid any inductive swing in VBUS reaching the chip. In short: don't connect it if it is bus-powered, and use a series resistor if powered from a separate supply.

Cheers,
Henk

Hi,
Thanks for the pointers. I cut the VBUS line that runs to the XMOS chip (I'm BUS POWERED). However, there is still no recognition on the host side.

Here is my current setup:
* I have #define SELF_POWERED commented out in customdefines.h
* verified that in main.c XUD_Manager is called with XUD_PWR_BUS.
* left USB_VBUS floating as specified in the XU216-512-TQ128 datasheet (dated 2017/02/02), figure 14.

And my current situation is:
* If I connect USB_VBUS, USB_DP is pulled high by the XMOS chip.
* If I leave USB_VBUS floating as in figure 14, USB_DP is never pulled high, and the host doesn't know that a device has been attached.

Is there another setting I need to set to let the thing ignore the VBUS pin?

I'm using the usb audio software: sw_usb_audio-6.15.2rc1, which seems to be the latest.

Thanks again,
-Caleb
henk
Respected Member
Posts: 346
Joined: Wed Jan 27, 2016 5:21 pm

Postby henk » Tue Feb 14, 2017 9:30 am

Hi Caleb,

Just checking - this is an undamaged chip is it?

Cheers,
Henk
User avatar
ccrome
Active Member
Posts: 44
Joined: Wed Sep 23, 2015 1:15 am

Postby ccrome » Tue Feb 14, 2017 8:28 pm

henk wrote:Hi Caleb,

Just checking - this is an undamaged chip is it?

Cheers,
Henk

That's right, and it's clearly sensing VBUS properly because I see it respond to the presence/absence of VBUS by pulling D+ up.

I found that if I self-power the board before USB is plugged in, it works reliably on every computer we've tried. However, if I bus-power it, it will work on some computers, but not on others.

The time from power applied to RST_N happens in 6ms. Is that still too long maybe?

Thanks,
--Caleb

Return to “Processors”

Who is online

Users browsing this forum: No registered users and 8 guests