AN01027 i2c issue Topic is solved

If you have a simple question and just want an answer.
__BriKs__
Active Member
Posts: 48
Joined: Tue Nov 27, 2018 9:45 pm

Post by __BriKs__ »

I have around 4.4V on the xmos side of R602 which is the resistor between USB_VBUS connector and Xmos pin23. Value of R602 is 10KR, on the other side of R602 I have 5.1V, this mean a current about 70µA.
I change R602 for a 1KR resistor in order to get more voltage, with 1KR the voltage on pin 23 of Xmos rise to 5V (for 5.1V on the connector side), so approx same current about 100µA.
But this change nothing I have always usb not working (descriptor failed) still with the xe file you gave me for hid test.


View Solution
User avatar
mon2
XCore Legend
Posts: 1913
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Post by mon2 »

So strange - are you able to test other USB ports on your PC? If possible, check on other PCs as well.

The focus at this time is to validate that the HID MOUSE IP functions on your custom PCBA. The ability to index and boot from the internal flash for the LED blinky is a very positive sign but baffled for now on why the USB MOUSE IP is failing - works fine here.

Will continue to review...
__BriKs__
Active Member
Posts: 48
Joined: Tue Nov 27, 2018 9:45 pm

Post by __BriKs__ »

I test on two PCs, one the older with USB2.0 black port and windows 7 64 bit, the other more recent with USB 2.0 et USB 3.0 windows 10 64, I test all ports on all PC.
Will start to work on the other side of my amp, the SPDIF receiver, still with XUF208, to see what works and what don't. Maybe will discover issue with PL611 this way.
User avatar
mon2
XCore Legend
Posts: 1913
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Post by mon2 »

Ok - sounds good to work on your AUDIO IP. A bit of caution on the XMOS reference audio IP, be sure to MASK off (remove from the run code) any access to the I2C devices that are NOT on your board. We have reviewed a number of OEM cases where the USB IP will break due to the audio IP retrying (2,000 times) before a timeout is raised due to the missing I2C slave device(s). These retries are blocking in nature and they will then cause the USP IP timing to break after running on the host PC over a period of time.
User avatar
mon2
XCore Legend
Posts: 1913
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Post by mon2 »

Hi. Can you check your resistor values for the NCP308 reset supervisor please? Are the values in the schematic correct?

What should be used here are values for R1 / R2 such that when the voltage on the 1V0 rail is 0.9V or higher, the #RESET output is released. That is, the #RESET = LOW till the 1V0 rail is > 0.9V.

See attached on what I believe is being selected as the threshold which does not look correct. Granted the LED blinky code is working but this may impact the USB enumeration timing.

I am calculating that the #RESET line will be open drain (ie. soft pulled high through R622 (2k2) if the 1v0 rail is @ 2v2 or higher?
ncp308_reset_threshold.png
(474.89 KiB) Not downloaded yet
ncp308_reset_threshold.png
(474.89 KiB) Not downloaded yet
Update: Place on ignore - just saw the 0.405 for Vit further in the document so this changes the trigger threshold to > 0.88 volts which is fine!!
__BriKs__
Active Member
Posts: 48
Joined: Tue Nov 27, 2018 9:45 pm

Post by __BriKs__ »

First page there is scope screenshoot of signal relative to reset. Then there was around 20ms between 1V stable and release of reset. I use a capacitor on CT pin to lower this delay to around 1ms and there is no change relative to usb issue.
I have to validate other parts of pcb, especially DAC and relative circuitry, that's why I focus now on SPDIF to I2S converter with Xmos. I'm learning and try to understand if I need or not external PLL CS2100 like on the demo board for my purpose.
I would like test USB on other PCB, for that I will modify layout and order new PCB, I'm confident in that USB issue is strange and sould work and would work on other PCB as many people with custom PCB and XUF208 don't have such issue.

Anyway I'm impressed and really grateful for your help mon2, I know Xmos is not the bigest company and having such a personalized support for me make me confident about Xmos is the right choice for my device. Hope in a near future buy thousands of chips :)

regards, Flo
User avatar
mon2
XCore Legend
Posts: 1913
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Post by mon2 »

Hello Flo.

Can you please post an updated schematic that details which parts are present in the Vbus line?

The external cable length along with onboard ceramic caps can lead to voltage spikes that can cause damaging effects on the Vbus pin of the XMOS device. Consider to see if you have the same latch up event by unplugging for a while for a possible reset.

Do consider the zener diode as noted by the developer here:

https://www.xcore.com/viewtopic.php?f=37&t=5808

Also if you are considering a PCB respin, highly recommend a proper USB load switch to be applied onto the Vbus line which offers many features including in-rush current protection, reverse voltage protection. Diodes inc. has some great parts we use in many of our designs.

If you have capacitance on Vbus line, remove it and test again. Allow for the PCB to be off for a few days and try again. Perhaps the XMOS CPU will need to be replaced.

The above thread is important to review about voltage spikes on USB lines.

Also to be clear, I am not an employee of XMOS but own a R&D company in Canada. History of product design dates back decades and we developed many industry firsts for the PC markets (PCI Express, etc.) We have the first USB product in our lab - courtesy of Logitech whom we designed the first plug and play adapter. Many war wounds to share and frequent this forum to assist when I can. Receiving too many emails from cases that could have been resolved before going into volume production.
__BriKs__
Active Member
Posts: 48
Joined: Tue Nov 27, 2018 9:45 pm

Post by __BriKs__ »

Hi mon2,

Here is a schematic reflecting the recents changes I made, so an up to date schematic
Xmos_USB.png
(93.88 KiB) Not downloaded yet
Xmos_USB.png
(93.88 KiB) Not downloaded yet
I can try remove the litle cap C625. And probe with my scope VBUS ringing when plug in order to see if there is high transcient like in the post you mention.

I didn't know how can be sensitive VBUS pin for Xmos device, so will add a vbus load switch just like you advise, in next pcb run.

Honestly I'm surpise you are not Xmos employee, the help you provide is something so generous, wonderfull exemple to follow.

Regards,

Flo
User avatar
mon2
XCore Legend
Posts: 1913
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Post by mon2 »

Please note that the series resistor on the Vbus line is required to be 10k.

Perhaps the value of 1k caused damage onto the XMOS CPU that is preventing the proper detection of the docking of this widget.

Has this value of R602 always been 1k?

Do you have another fresh PCB that can be soldered with a fresh XMOS CPU to test again?

vbus_transient_supressor.png
(232.79 KiB) Not downloaded yet
vbus_transient_supressor.png
(232.79 KiB) Not downloaded yet
__BriKs__
Active Member
Posts: 48
Joined: Tue Nov 27, 2018 9:45 pm

Post by __BriKs__ »

Indeed, I had 10KR and I test 1KR to see if something change, but not.
I had fresh PCB but few components, will focus on making work the SPDIF and then the DAC. After I will modify the PCB with confidence than USB will works, certainly with a load switch on VBUS.
Post Reply