Weird behaviour of custom USB to SPDIF bridge
Posted: 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!
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!