porting USB Audio to xu208 / does not enumerate

Sub forums for various specialist XMOS applications. e.g. USB audio, motor control and robotics.
mrtok
Member
Posts: 11
Joined: Fri Nov 11, 2016 8:30 am

porting USB Audio to xu208 / does not enumerate

Postby mrtok » Fri Nov 11, 2016 8:46 am

Hi all,

we try to adopt the multichannel reference board xcore200 v2.0 to our DAC design. We followed the design guide lines and the porting appnote to change xn files et al.

What we see when powering up the device:
We are able to download/flash/debug with our own PCB but when it comes to USB bring up we got stuck. Enumeration does not work.

Observations of the D+/D- lines on the scope (low speed only) shows lots of packets rushing. Withing our test design (AN00182 - HID example to keep it simple) we put some logmessages.

As we suspected the D+/D- lines connected in a wrong way we put another USB jack on the buttom side of the USB and connected appropriatly to test that.

Case a.) D+/D- as design in our PCB
Case b.) inverted

In case a.) within EP0 function we see XUD_RES_RST with different usb_speed (FS,HS) - case b.) only shows XUD_RES_RST in fullspeed (FS).

Changes we did in Endpoint0.xc of AN00182 to get this loggings:

Code: Select all

/* Returns XUD_RES_OKAY on success */
        XUD_Result_t result = USB_GetSetupPacket(ep0_out, ep0_in, sp);

        switch (usbBusSpeed)
        {
        case XUD_SPEED_FS:
        {
            printstr("XUD_SPEED_FS - result=");
        } break;
        case XUD_SPEED_HS:
        {
            printstr("XUD_SPEED_HS - result=");
        } break;
        }

        if(result == XUD_RES_OKAY) {
            printstr("XUD_RES_OKAY\n");
        } else if (result == XUD_RES_RST ) {
            printstr("XUD_RES_RST\n");
        } else if (result == XUD_RES_ERR ) {
            printstr("XUD_RES_ERR\n");
        }

        if(result == XUD_RES_OKAY)

trace output case a.):

Code: Select all

XUD_SPEED_FS - result=XUD_RES_RST
XUD_SPEED_FS - result=XUD_RES_RST
XUD_SPEED_HS - result=XUD_RES_RST
XUD_SPEED_FS - result=XUD_RES_RST
XUD_SPEED_FS - result=XUD_RES_RST
XUD_SPEED_HS - result=XUD_RES_RST
XUD_SPEED_FS - result=XUD_RES_RST
XUD_SPEED_HS - result=XUD_RES_RST
XUD_SPEED_FS - result=XUD_RES_RST
XUD_SPEED_FS - result=XUD_RES_RST
XUD_SPEED_FS - result=XUD_RES_RST
XUD_SPEED_FS - result=XUD_RES_RST
XUD_SPEED_FS - result=XUD_RES_RST
XUD_SPEED_HS - result=XUD_RES_RST


We not see any other "result" than RST - no OKAY for example and no ERR !?

As we are currently not enabled to use a USB analyzer we cannot see why this fails. Are there any possibilities to track this down (e.g. by using state registers of the USB PHY)?

thanks,
thomas
User avatar
mon2
XCore Legend
Posts: 1358
Joined: Thu Jun 10, 2010 11:43 am

Postby mon2 » Fri Nov 11, 2016 12:48 pm

Can you share your (partial ?) schematics for a review ?

Can you share your (partial is ok ) PCB layout for the USB region for a review ?

Proper guidelines followed for the multi-layer PCB layout with respect to impedance matching ?

Use software tool to log the USB packets and post here for a review.

For example (just a random search using google but we have used HHD tools in the past):

http://freeusbanalyzer.com/
User avatar
mon2
XCore Legend
Posts: 1358
Joined: Thu Jun 10, 2010 11:43 am

Postby mon2 » Fri Nov 11, 2016 1:16 pm

We are able to download/flash/debug with our own PCB


Can you flash your PCB with firmware to blink a LED (as an example) and after this firmware is made non-volatile, your PCB will boot ok and blink the LED upon each power up cycle ?

Just trying to confirm if the QSPI flash needs to have the QSPI bit enabled or not. However, the flash memory really should not be required at this time if you are able to use the XTAG tool to inject and run your code out of ram.
mrtok
Member
Posts: 11
Joined: Fri Nov 11, 2016 8:30 am

Postby mrtok » Fri Nov 11, 2016 1:20 pm

Hi mon2,

please find attached small snipped of the layout, schematic and HHD tool trace (very short).

I am working on a mac but i tried this on windows.

impedance matched differential pair routing was used for USB D+/- trace width 0.33mm distance 0.15mm. standard layer stack. hopefully this not too bad :-/

thanks.

Update: can flash QSPI - but also can use debugger and so on - so i guess general setup is fine...
You do not have the required permissions to view the files attached to this post.
User avatar
mon2
XCore Legend
Posts: 1358
Joined: Thu Jun 10, 2010 11:43 am

Postby mon2 » Fri Nov 11, 2016 1:41 pm

What is the CPU clock value ? For USB support, must be a multiple of 24 Mhz. Are you using the pre-programmed Si5351A PLL in your project ? If yes, confirm the clock values from this PLL to be correct.

No ESD protection devices are visible in the schematic nor PCB layout. Highly recommend that ESD protection be placed along with current limit protection on the Vbus line (ie. polymer fuse which will reset after the fault is corrected as a minimum level of current protection). Search this user forum for some ideas. Otherwise, the processor (any vendor is in the same boat) can be damaged and will lead to a RMA for your side with a growing pile of defective products and a poor user experience.

The issue may not be ESD related at this time so continue to debug...

a) does the same Windows s/w tool offer packet level details ? Try to expand the tool to capture and log to post the packets (if any) being broadcasted.

b) does your PCB design allow for uploading of simple LED blinker code ? Can you save the same code into flash and the PCB will power up to boot your blinker code ?

c) have you uploaded the firmware to support the USB interface onto your PCB ?
mrtok
Member
Posts: 11
Joined: Fri Nov 11, 2016 8:30 am

Postby mrtok » Fri Nov 11, 2016 1:47 pm

mon2 wrote:What is the CPU clock value ? For USB support, must be a multiple of 24 Mhz. Are you using the pre-programmed Si5351A PLL in your project ? If yes, confirm the clock values from this PLL to be correct.

No ESD protection devices are visible in the schematic nor PCB layout. Highly recommend that ESD protection be placed along with current limit protection on the Vbus line (ie. polymer fuse which will reset after the fault is corrected as a minimum level of current protection). Search this user forum for some ideas. Otherwise, the processor (any vendor is in the same boat) can be damaged and will lead to a RMA for your side with a growing pile of defective products and a poor user experience.

The issue may not be ESD related at this time so continue to debug...

a) does the same Windows s/w tool offer packet level details ? Try to expand the tool to capture and log to post the packets (if any) being broadcasted.

b) does your PCB design allow for uploading of simple LED blinker code ? Can you save the same code into flash and the PCB will power up to boot your blinker code ?

c) have you uploaded the firmware to support the USB interface onto your PCB ?


thanks for your advice regarding esd/current protection.

ad a) no i tried to dive into packets without success
ad b) c) I can run and debug code on our PCB - we use a 24MHz osc.

sure could try to run a blinker code (without LED, but a pin) but i think because ability to debug (run/stop breakpoints et al - logmessages) everything should be ok. !??
User avatar
mon2
XCore Legend
Posts: 1358
Joined: Thu Jun 10, 2010 11:43 am

Postby mon2 » Fri Nov 11, 2016 1:52 pm

sure could try to run a blinker code (without LED, but a pin) but i think because ability to debug (run/stop breakpoints et al - logmessages) everything should be ok. !??


Yes, is fine. Just trying to confirm that the custom PCB has valid power up cycle, flash device is able to self boot with any custom code. Sounds like the PCB is ok so far with respect to these concerns but do attempt to run some simple code to validate.

==========

This XU208 XMOS processor requires the installation of a 43R2 1% resistor onto pin 24.

See this in your schematic but unable to locate this resistor on your (posted) PCB layout.

Is R2 placed and relatively close to pin 24 ? This pin should be close to the D+ on the processor (ie. pin 25 = D+).

You have a ground to the metal belly of the XU208 in your PCB layout ?

Power supply sequencing ok ?
mrtok
Member
Posts: 11
Joined: Fri Nov 11, 2016 8:30 am

Postby mrtok » Fri Nov 11, 2016 1:52 pm

mon2 wrote:
sure could try to run a blinker code (without LED, but a pin) but i think because ability to debug (run/stop breakpoints et al - logmessages) everything should be ok. !??


Yes, is fine. Just trying to confirm that the custom PCB has valid power up cycle, flash device is able to self boot with any custom code. Sounds like the PCB is ok so far with respect to these concerns but do attempt to run some simple code to validate.

will do.
==========

This XU208 XMOS processor requires the installation of a 43R2 1% resistor onto pin 24.

See this in your schematic but unable to locate this resistor on your (posted) PCB layout.

Is R2 placed and relatively close to pin 24 ? This pin should be close to the D+ on the processor (ie. pin 25 = D+).

You have a ground to the metal belly of the XU208 in your PCB layout ?

Power supply sequencing ok ?

Power sequencing copied from ref design - ok.
GND die attach pad is connected.

thanks,
thomas
You do not have the required permissions to view the files attached to this post.
User avatar
mon2
XCore Legend
Posts: 1358
Joined: Thu Jun 10, 2010 11:43 am

Postby mon2 » Fri Nov 11, 2016 1:56 pm

Another s/w only USB packet capture tool for Windows to try:

http://desowin.org/usbpcap/

Recommended by Jan Axelson.

reference:
http://janaxelson.com/development_tools.htm
mrtok
Member
Posts: 11
Joined: Fri Nov 11, 2016 8:30 am

Postby mrtok » Mon Nov 14, 2016 8:57 am

hi,

i tried several capture tools - usbpcap was not able to capture this.

device listed as errored device - code 43 - error during getting device descriptor.

still no clue?

Who is online

Users browsing this forum: No registered users and 2 guests