Migrating from XHRA to XU208

Discussions about USB Audio on XMOS devices
sleepfox
Member++
Posts: 16
Joined: Fri Jun 01, 2018 5:03 pm

Post by sleepfox »

Hi, Mon2,

Thanks for checking the schematics for me.

1) R3 is 10K ohm. The output voltage is formed by dropping 100uA constant current on this resistor. 10Kohm*100uA should gives an output voltage of 1V. R4 is 4.7ohm, as in the original XHRA schematics. It forms a RC network with a 0.1uf cap and 1V power supply for PLL_AVDD. R5 is 43.2ohm as in the XUF208 datasheet -- to pull USB-Rtune to ground through this resistor.

2) LT3045 also has power monintor function. PG pin is a open-collector output that pulls low when PGFB sense a voltage under the threshold of 0.3V. Therefore you may use a pair of resistors that divides the output voltage, for example, if the lower position resistor is half of the upper resistor, then PGFB sense 1/3 of output voltage -- when the output voltage is less than 0.9V, then PG will pull low (since PGFB is below threshold of 0.3V). Originally I thought this could be a very neat way to satisfy the required reset time when XMOS boots. However, according to XUF208 datasheet, "RST_N and must be asserted low during and after power up for 100 ns" and I am not sure this timeing requirement could be met with LT3045's power monitor function. I ended up abondoning this idea and adding a STM6717. Have to play safe on this one since 4-layer pcb and xmos chip are not cheap. I am very interested to see if this idea of power monitor works though. If any one ever try it with success, do let me know. Thanks.

3) According to 1) and 2), the two resistors in the attched figure do not define output voltage, they could be used in a way that PG pin monitors output voltage though, they can also be added so that the LT3045 has a fast startup, which is the purpose of the schematics that you attached. R3 (which connects the SET pin to ground) defines the output voltage.

Thanks again.


sleepfox
Member++
Posts: 16
Joined: Fri Jun 01, 2018 5:03 pm

Post by sleepfox »

Hi, Mon2,

About the voltage divider in the schematics that you attached. The values were configured in a way that the PGFB pin senses 10% of the output voltage. This is a fast startup configuration. Instead of normal 100uA current, the chip send 2mA current to Rset (and charges its large bypass capacitor) so that the voltage upon Rset (which is also the output voltage) can reach target 3.3V very fast. Once the output voltage is close to 3.3V, the pin PGFB sense a volatage higher than 0.3V threshold, and the chip then stops the 2mA current, and supplies normal 100uA current thereafter (otherwise the voltage on Rset, and thus the output voltage, will keep rising pass 3.3V target). Cheers.
sleepfox
Member++
Posts: 16
Joined: Fri Jun 01, 2018 5:03 pm

Post by sleepfox »

And like I said in post 2) of post 101. I once thought about using LT3045 only (without a power monitor IC) to monitor the power and boot sequence. Attached is the schemtics that I once drew for this idea.
Attachments
LT3045_Power_Monitor.jpg
(129.44 KiB) Not downloaded yet
LT3045_Power_Monitor.jpg
(129.44 KiB) Not downloaded yet
CraneTech
Newbie
Posts: 1
Joined: Tue Sep 04, 2018 10:18 pm

Post by CraneTech »

Hello, I am currently trying to upgrade to the XU208 as detailed in this thread and am having some difficulties. I’m using a pretty basic test board that takes USB in and has a SPDIF out. I’ll also need the I2S audio out for the full project the XU208 is going into, but on the test board the default stereo I2S pins aren’t connected to anything.

The project is compiling and loading correctly (apparently). The issue is that the firmware seems stuck at 384k sample rate and not recognizing the incoming sample rate. It does receive a USB audio stream in certain cases, but the I2S output is stuck at 384k (with no SPDIF out because of that). The provided project is essentially unchanged (just tweaked a few options in customdefines.h).

I’m messing around with troubleshooting it, but at this point I’m kind of looking for any possible suggestions on possible causes. The XU208 is being clocked from an external 24 MHz oscillator, but it looks like the project is set up to compile for that configuration already.

Thanks for any input you guys might have.
User avatar
mon2
XCore Legend
Posts: 1913
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Post by mon2 »

@CraneTech, can you code up a simple led blinky and upload to your custom pcb for testing? Does that blinky code work ok?

Another suggestion is to test your custom board with one of the xmos supplied usb hid code, usb mouse or usb cdc demo codes. Do they run ok on your pcb?
User avatar
infiniteimprobability
XCore Legend
Posts: 1126
Joined: Thu May 27, 2010 10:08 am
Contact:

Post by infiniteimprobability »

ANother thing to do is to use the debugger (or even do xrun --dump-state) to see where the code is - is it stuck, has there been an exception, if so which thread, at what line of code etc. etc.. It's very hard to suggest what to do without more debug visibility. Otherwise you are debugging blind and it's largely guess work.

Also does it work if you limit MAX_FREQ to 192000? How do you know it's stuck on 384000?
shaw
Active Member
Posts: 43
Joined: Fri Mar 25, 2011 12:36 am

Post by shaw »

We are starting development on a new audio product. It will be identical to the XK-USB-AUDIO-HPA evaluation board, but we will replace the obsolete HXRA device with an XU208. The product is intended to support sample rates upto and including DSD4x.

While this new board was being developed, I worked with the XCore200 board, just to get some experience with the USB Audio 2.0 Reference software. I was told by Xmos FAE that the latest version of reference software (v 6.15.2rc1), did not support dsd. So I went back to prior version (6.12.6), and I was able to get dsd4x to work on Xcore200.

Now that our new boards are back, I have followed infiniteimprobability's migration guide. I have tried migration using both version of USB reference software (v6.15.2rc1 and 6.12.6). I was able to make progress with version 6.15.2 and was able to get I2S outputs beginning to work. With version 6.12.6 I have not made any real progress on getting the I2S outputs to work.

So I have to make the decision on what version of USB reference software to use. I can use 6.15.2, that this migration document is based on, but it might not support DSD4x. I can use 6.12.6 that DSD4x has worked on xcore 200, but I'm having no luck with migration to XU208 and the migration to 208 has not necessarily been proven out on this code base.

Has anyone had any success with this migration to XU208, using version 6.15.2 and gotten DSD to work?
Has anyone successfully migrated to XU208 using version 6.12.6?


Thanks for any help.
User avatar
infiniteimprobability
XCore Legend
Posts: 1126
Joined: Thu May 27, 2010 10:08 am
Contact:

Post by infiniteimprobability »

Has anyone had any success with this migration to XU208, using version 6.15.2 and gotten DSD to work?
Checkout the first post in this thread:
- Includes DSD fix for the above release (see thread viewtopic.php?t=5010)
DSD should work fine on 6.15.2 with the patch provided in this thread (and was tested).. How exactly is it failing?
shaw
Active Member
Posts: 43
Joined: Fri Mar 25, 2011 12:36 am

Post by shaw »

thank-you for clarifying. I now understand that DSD has been verified to work using ver 6.15.2rc1 for this migration. All my comments will be based on using that version of software on our board, (which is identical to the XK-USB-AUDIO-HPA evaluation board).

Now that I look more closely at I2S bus on logic analyzer, with DSD playing, it doesn't appear to be failing uniquely. It seems to be behaving similar to when I play any wav files:
1: I am running code using Xmos xTIMEcomposer debugger (xTIME composer v14.3.3, via Xmos xTAG 3 1v2 ).
2: I am using JRiver Media Center 24.
3: I'll stay focued on running all tests with a 44.1K sampling rate or one of the multiples, up to 352,800.
4: Thesycon eval driver, v4.11.0.0

Once I launch debugger, program starts and successfully enumerates as an XMOS USB 2.0 audio Device (XMOS-XHRA-2HPA (EVAL)). I then play a 44.1K wav file. LR clock and bit clock look correct, but no data. When I then try to play another wav file at a different sampling rate, it plays on Jriver but the LR clock and bit clock are unchanged from when it was playing 44.1K, and still no data.
If I cycle power and repeat with a faster sampling rates, LR clock and bit clock look good. But playing subsequent wav files at other sampling rates, will play, but clocks stay fixed at initial rate AND still no data.
User avatar
infiniteimprobability
XCore Legend
Posts: 1126
Joined: Thu May 27, 2010 10:08 am
Contact:

Post by infiniteimprobability »

Hmm sounds like the problem is on sample rate change. Could be AudioHwConfig is getting stuck. (where does the debugger say the audio thread is?) Try commenting out suspect bits if that function - could be I2C config issue?
Post Reply