Weird behaviour of custom USB to SPDIF bridge

If you have a simple question and just want an answer.
Lorien
Member++
Posts: 21
Joined: Wed May 19, 2010 9:07 am

Weird behaviour of custom USB to SPDIF bridge

Postby Lorien » Wed Mar 21, 2018 10:28 pm

Hello,
I'll try to be as short as possible without getting you bored with my details! I'm coming here in desperately searching for help regarding one of my latest designs which are based on the old but trusty USB Audio stereo bridge designed back in 2010 or so. Link here: https://www.xmos.com/support/boards?product=14772. At least I think is that board since I cannot see any photos. Anyway, my application processor is XS1-L6A-64 (or, occasionally the 8 core alternative) in TQFP48 pin package, C5 variant. The long story short is this one: my board is playing with occasional clicks on audio stream in Windows OSes using latest legit Thesycon driver package I have (v4.14). By occasional I mean one click at 10-15 seconds or so but it's not a tight value. Sometimes, some of my clients said that it's like listening to a vinyl :) so I'm assuming those clicks are more than a few per minute...
On MAC there is not problem at all while...
on Linux, especially Ubuntu, LTS16.04 or so, the playback is 99% wrong. By "wrong" I mean that tracks are playing like there's a higher master clock used. The pitch is heavily speed up and there are a lot of clicks coming along with the music. Basically, there's no chance in listening to that music at all... unless you want to kill yourself! I have never experience any of such music played with lower pitch than normal... only higher!
I'm fighting with this issue for almost one year without finding any real clue where this strange behavior is coming from! What I can be 100% certain is that it's from the hardware!
How's that?... you may ask! Well, I have an early design built around the same reference design from XMOS and that board is also made 100% by me and is playing nicely on all the OSes I'm throwing at it! But there's a slight different XMOS chip on it (basically the same as above but in TQFP128 pin package). On both designs I'm using external ULPI interface: USB3318. System clock for both ULPI and XMOS chips is coming from an external 13 MHz clock source. The single major difference between these two designs is the fact that on the troubled design, the "audio clocks" and the related multiplexer are located on the isolated side of the PCB with no direct ground connection to the USB side.

What I've done so far:
1. I've bridged the isolator chip (all pins of it) seeing if there's a problem with the induced jitter of it. Both PCB sides (USB and isolated) were powered form USB bus with direct/thick GND connections! No positive results, board is acting the same.
2. I've redesigned the USB input by making a second PCB revision, taking into account the 90 R differential impedance required for the USB data signals. I spoke with the PCB manufacturer and built up a PCB layout choosing a specific laminate after which the thickness of the USB data traces and the distance between them were chosen. Antipads were taken into account, stubs were eliminated, there are no ground/power traces under the USB connector. USB shield was connected to GND through a TVS || 10nF || FBead. the results are the same.
3. on the third PCB I redesigned the traces between the ULPI and XMOS processor by length matching all of them except the USB reset signal. Same story - useless!
4. I placed the 13 MHz clock oscillator as close to the XMOS processor as possible, even if that oscillator was/still is located on a corner of the PCB. No changes whatsoever!
5. I've completely disabled all the "audio oscillators" from the isolated side and built a small test PCB with two of them (22.5792 MHz and 24.576 MHz) located as closest to the XMOS processor as possible. This time there was NO isolation barrier between the clock sources and XMOS. Well, useless!
6. Now I'm heavily running out of options! The firmware is 99% based on the board that's working! Taking into account that my newly chosen XMOS processor is in fact like the old one with a different package. I simply had to change the pin declarations in the .xn to adapt for the new schematic file and recompile the project. Taking this into account, there were minor changes to the firmware that's why I say it's 99% like the old and functional one I have for my old board!
7. There are many things I can enumerate here since I tried many of my ideas in the past year!

I forgot to say that all the signals (clocks, output signals, ULPI signals power, etc), were checked with my 350 Mhz Picoscope and all of them are in 3.3V limits. There is none that has a wide over / undershoot. All were dampened using serial termination resistors.

I spoke with Ross at XMOS and I want to thank him for his time in replying to my messages! He told me the problem might be related to an USB transfer! And, because of that and the fact that I'm using same chips for the old an new design (except the package difference) I blamed my lack of skills in layoutting the USB data paths. But I saw the other days that, despite to all me efforts, the problem is still there!

I REALLY hope there's someone here who has a clue on what is happening on my design! Please note that I have scarce knowledge in programming the XMOS processors other than changing a couple of declarations or pin mapping! That was the main reason why I didn't "played" with the firmware and tried to keep it as close to 'original' XMOS release as possible. All my HW changes were made by consulting the possibilities in firmware first!

I'm looking forward to any answer it might help me putting this nightmare to an end!
Thank you for your time and excuse my english!
User avatar
mon2
XCore Legend
Posts: 1166
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Postby mon2 » Wed Mar 21, 2018 11:01 pm

Hi. Can you share a schematic? Can send in a private email if you wish? PCB layout?

When you say isolated, which isolators? At which stage did you perform this isolation? Respectively, what are the details of your isolated power supply?

What is the spacing of your isolation barrier?

Have you tested other brands of isolators? Although changing the processor package should not pose an issue I would think so your isolators could be kept the same.

How many layers are your PCBs? At least 4L I hope?

Using the same official Windows driver, do your earlier version of the design raise any audible pop clicks?

Are you using a reliable contract manufacturer for the assembly of these new PCBs? Many many of the emails I have received for debug assistance is related to the quality of the build or bill of materials and then IP itself.
User avatar
mon2
XCore Legend
Posts: 1166
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Postby mon2 » Wed Mar 21, 2018 11:11 pm

22.5792 MHz and 24.576 MHZ


is on your board but the XMOS ref design is noting the use of:

Image

Or are you doing something kinky or using a different DAC with your design that requires the other clock values?
User avatar
mon2
XCore Legend
Posts: 1166
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Postby mon2 » Thu Mar 22, 2018 5:26 am

tracks are playing like there's a higher master clock used.


Yes, unless you have added an external divide by 2 for the 22.5792 MHz clock oscillator, this is the wrong value for the clock and is too fast for the codec and the reference IP.

What are the crystal values used in your original working design? Suspecting the clocks on the working version of the design are 11.2896 Mhz and 24.576 Mhz.

Image

Assuming the above is correct, the resolution options are:

1) replace the non-working 22.579 Mhz clock source (crystal) with a 11.2896 Mhz and continue to use the default IP from XMOS.

OR

2) leave the clocks as-is but add support for the higher MCLK value into your firmware as follows:

a) review the following register value for the CS4270 Codec (Cirrus Semiconductor)

if this register is not used by the XMOS IP then the register is power default at a value of 1, so compensate for your higher external clock by using this internal register to configure for divide by 2 when MDIV2 pin (driven by the XMOS CPU) is LOW. When MDIV2 pin is LOW, the 11.2896 Mhz is selected but if you have installed a 22.579 Mhz clock then this register with a Divide by 2 feature will compensate.

When MDIV2 pin HIGH, the 24.576 Mhz clock source is selected which is correct so need to configure this same internal register as Divide by 1 - so that you do not break this alternate clock source and related sampling values :)

Image

If you have the ability to apply field upgrades to your widget then the software fix may be the practical choice else will need to rework the boxes.

Disclaimer: Do not have this board but the root cause and fix sound logical. If you indeed did apply an external flip-flop to divide the clock by 2 with a 22.579 Mhz crystal then you should be fine for the generation of the 11.2896 Mhz clock source and can ignore my ramblings.
Lorien
Member++
Posts: 21
Joined: Wed May 19, 2010 9:07 am

Postby Lorien » Thu Mar 22, 2018 8:59 am

Hello mon2 and thank you very much for all your time in writing your posts, it's highly appreciated!
I'll answer to all your questions one at a time!

mon2 wrote:Hi. Can you share a schematic? Can send in a private email if you wish? PCB layout?

yes I can do that and I would gladly do it for all of you but I have a real problem with chinese / South Korea / Hong Kong copycats and cloners. I know from my own experience how it is to be cloned and copied... that's the main reason I'll send you the infos you need through PMs so a private email address would be nice to have.

mon2 wrote:When you say isolated, which isolators?

At some point I assumed there could be a problem related to the quality (read "jittery behavior") of the master audio clock signal. Initially I used the Silicon Labs' SI8641BB-B-IS1 isolator but later on I switched with IL717-3E from NVE. Both come in (narrow) SOIC16 package. Even if my scope is not a very good one, I could see the jittery edges of the master audio clock passing through the SI8641BB-B-IS1 isolator... which were higher than those I saw on IL717-3E alternative. Anyway, in both ways there's some added jitter on that master audio signal after the isolator that's why, at some point, I decided to completely remove the isolator and solder wires instead on data paths thus completely bypassing it. I suspected this will solve the problem but was not the case.

mon2 wrote:At which stage did you perform this isolation?

The path of the master audio clock signals is like this:
22.5792 MHz AND 24.576 MHz signals from those dedicated oscillators are MUXed by NC7SZ157 multiplexer part => the output of this MUX is directly connected to the isolator input => || here's the isolation barrier || => the isolator output is feeding the XMOS master clock input pin. So I can safely say the isolation is between the XMOS processor and the main "audio" oscillators.

mon2 wrote:Respectively, what are the details of your isolated power supply?

I'm working with 3.3Vdc power supplies on both sides of the isolator. Each power pin of the isolator is decoupled with 110nF || 1uF and connected to the rest of the power rail through a FB of 120 ohms @ 100 MHz. The isolated side can be powered from USB Bus or external PSU by means of a relay. It has its own low noise Vreg with 3.3V output.

mon2 wrote:What is the spacing of your isolation barrier?

A rough pad to pad distance measures in PCB CAD I'm using gives me a 4 mm value. Under the isolator, I simply removed the PCB laminate by routing a (unplated) slot which is a long as the isolator chip itself.

mon2 wrote:Have you tested other brands of isolators?

There are two different parts for now, made by two different manufacturers. When I saw that bypassing the isolator with wires gave me no favorable results I doubted that buying a third isolator will solve anything on this path.

mon2 wrote:How many layers are your PCBs? At least 4L I hope?

Yes, there are 4 layers configured in: TOP / GND / PWR / BOT stackup
As you will see, the GND layer is a fully one, except a tiny region, removed under the USB connector.

mon2 wrote:Using the same official Windows driver, do your earlier version of the design raise any audible pop clicks?

No, never! I'm fully trusting in Thesycon's drivers. I'm using them starting with 2010 when my first product came out and never had any issues with those drivers! I can say that are 'rock' stable.

mon2 wrote:Are you using a reliable contract manufacturer for the assembly of these new PCBs? Many many of the emails I have received for debug assistance is related to the quality of the build or bill of materials and then IP itself.

I thought at this too! The first PCB I made for this troubled design was sourced by a cheap chinese PCB manufacturer (PCBWay) which I never used them before. When I heard how this board is acting I thought they might change the Prepreg laminates in such a way to be easier and cheaper for them. Currently there's no way for me to measure the copper and prepreg thickness of all the boards I got from them so I had to trust them blindly. Anyway, later on I decided to make a new batch of test boards, taking all the necessary precautions and be sure that my boards were made as I wished! So I've chosen the same PCB manufacturer I'm using for my old but stable design. After some weeks in exchanging emails with them, we decided what prepreg / copper thickness / core laminates had to be used for my (troubled) board.
The weird thing is that all my(troubled) boards (from both cheap and reliable chinese PCB manufacturer) are acting the same on my laptop.

Sadly I have to go now to solve some personal issues but I'll get back to you later on and answer to all your questions.
Again, thank you very much for all your time and effort,
L
User avatar
mon2
XCore Legend
Posts: 1166
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Postby mon2 » Thu Mar 22, 2018 11:47 am

Hi. Ok.

1) But why is there a 22.5792 MHz clock on your board instead of the 11.2896 Mhz? This higher clock value could be the reason for the raised issues.

2) What are the clock (crystal) values on the earlier version of the working PCB?

3) We have used both NVE (when they first launched the line) and Silabs isolators in very high volumes with success but not used in audio field. There is also TI and Analog Devices you can review for isolators but since you have bypassed the isolators and still have the quirks, that is likely not the root cause. Continue to test without the isolators to confirm the issue is fixed and then only introduce the isolators and then test again.
Lorien
Member++
Posts: 21
Joined: Wed May 19, 2010 9:07 am

Postby Lorien » Thu Mar 22, 2018 8:58 pm

Just arrived home thus didn't had proper time to answer to your previous questions but I'll do it to your last post just to keep things in some sort of order.
My previous design had (still have) same kind of clock oscillator freqs: 22.5792 MHz and 24.576 Mhz. The main goal was that it was hard to me to buy the 11.xxx alternatives while the market pushed me to support
352 fs and 384 fs. I couldn't do it with 11.xxx base clock. So, I put the 22.xxx Mhz clock part instead of 11.x Mhz and changed one file in firmware. I guess it was the "customization.h" or something like this.
After that all went okay for that first board so had no troubles in 7 years!
So, with actual troubled design, my goal is to have an USB to SPDIF interface thus any DACs or ADCs aren't available on my PCB. In addition, those routines that are controlling the DACs/ADCs through I2C were removed from firmware.

But, the problem is NOT tied to a specific family of frequencies... No! The problem is affecting ALL the sample rates: from 44.1, 48 up to 192 KHz. On Linux (the most affected OS), that weird playback is taking place from 44.1 fs up to 192 fs. It gives me No break!
Based on that, I'm assuming the problem is not tied to the frequency values of the base clock oscillators but something along the line (between oscillators and XMOS) or even in XMOS chip itself!
I still have to dig into hardware but I have no more options left to try....
Meanwhile I'll try to contact Ross and kindly ask him for his opinion and support on this... whenever he has some spare time to do it!
I really hope with help of all of you I'll find a solution which is other than a huge hammer (already considered).
Kind regards,
L
User avatar
akp
XCore Addict
Posts: 197
Joined: Thu Nov 26, 2015 11:47 pm

Postby akp » Thu Mar 22, 2018 9:32 pm

Just wondering if you tried it with the same computer booting different OSes -- at least for me it helps to dual boot my laptop to Linux and Windows and use everything else the same (i.e. my device under test, too). That way I get an indication if it's just an OS interaction with the firmware. With the Linux playback really fast, do you have an idea how fast it is? e.g. 2x? That might give a clue as to the problem. One more thing, to clarify, the good and bad board are both USB to SPDIF?
User avatar
mon2
XCore Legend
Posts: 1166
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Postby mon2 » Thu Mar 22, 2018 9:42 pm

Ok. Can you send over what you wish via PM? We are not audio developers but who know what our 4 eyes may find. Ideally, schematic + gerbers. IP if you wish to check against the XMOS refference design. Given that this migrated design has not worked properly, perhaps related to the firmware?

We recall meeting the same PCB shop last October at the HK Fair. They had a nice booth but they do have alias fronts - known under other company names as well. IMHO, there are higher quality shops but are more $$$. For example, JETPCB is one of the best and in Taiwan. They are also in the US for sales. I recall meeting them in Taiwan and used them for at least 20-50 projects with zero issues. Just a bit pricey compared other shops in Asia. A steal compared to our local shops. You can also try ICAPE (assorted offices around the world). Always at the trade fairs with a large booth and many staff members. The owner was here for an afternoon and he has ties with many PCB shops in Asia. Respectively can beat them up if there is any issue with his local staff in Shenzhen, etc.
User avatar
mon2
XCore Legend
Posts: 1166
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Postby mon2 » Sat Mar 24, 2018 5:51 pm

On MAC there is not problem at all while...


Now that is weird. No issue at all on the MAC platform? If true, then it cannot be an issue with your hardware could it?

What are the details of the USB ports that work on the MAC? USB3.0 or USB 2.0?

What are the details of the USB ports that do not work on the PC platform? Black insulator = USB 2.0 or Blue insulator = USB 3.0?

Respectively, if you use the same non-working USB port on the PC with the older design, it works?

Who is online

Users browsing this forum: No registered users and 13 guests