XCORE-200 VBUS

Technical discussions around xCORE processors (e.g. xcore-200 & xcore.ai).
User avatar
ccrome
Active Member
Posts: 62
Joined: Wed Sep 23, 2015 1:15 am

XCORE-200 VBUS

Post by ccrome »

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 Legend
Posts: 1913
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Post by mon2 »

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: 62
Joined: Wed Sep 23, 2015 1:15 am

Post by ccrome »

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: 62
Joined: Wed Sep 23, 2015 1:15 am

Post by ccrome »

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 Legend
Posts: 1913
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Post by mon2 »

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:

http://www.xcore.com/viewtopic.php?f=26 ... e&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: 347
Joined: Wed Jan 27, 2016 5:21 pm

Post by henk »

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: 52
Joined: Mon Jan 19, 2015 12:47 pm

Post by dweeb4 »

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: 62
Joined: Wed Sep 23, 2015 1:15 am

Post by ccrome »

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: 347
Joined: Wed Jan 27, 2016 5:21 pm

Post by henk »

Hi Caleb,

Just checking - this is an undamaged chip is it?

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

Post by ccrome »

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
Post Reply