native DSD is working SOMETIMES... Topic is solved

Sub forums for various specialist XMOS applications. e.g. USB audio, motor control and robotics.
kasemann
Member
Posts: 11
Joined: Tue Dec 20, 2016 4:09 pm

native DSD is working SOMETIMES...

Postby kasemann » Thu Jan 12, 2017 12:31 pm

Hi

we have a design based on the xMos Audio-HiRes-2-DAC-HPA reference platform - only we are using a flash xMos chip (XUF208-256-TG64-C10) instead. We ported one of the example projects in the USB-Audio reference code according to AN01027.

Everything is working fine so far (USB Connection is working; playback of a multitude of formats is working - fine and stable). The only problem is with native DSD (I only briefly checked on DoP - that seems to be working reliably, I'm getting clicks during playback, hower, but this could be related to the Android host).

The native DSD problem:

First, when playing back native DSD with foobar it just produced very loud noise or hiss at the output (foobar settings seem to be correct - it works fine with the Audio-HiRes-2-DAC-HPA eval board). After reading some on this forum I tried using an older code base (6.12.6) instead of 6.15.6. After that DSD worked SOMETIMES - it seems to work more often when I run the project using the debugger, but basicly the problem is the same with flashed versions of the code:

After connecting the device to the PC (powering it up in the process) DSD either works or it doesn't. When it doesn't, I found out that the stream is not identified as DSD and handled (at least in AudioHw) as a 176kHz PCM stream (in 64DSD case). A constant low amplitude noise is output from the DAC then.

While connected I can feed different audio formats and sampling rates to the device and they all work fine. When DSD is working, it stays that way until I remove/reconnect the device. The same holds true for DSD not working.

On average I would guess that DSD is working on every 3rd connection. I tried downgrading the toolset to 14.0.4, but that didn't help. I also reduced the optimization level from -O3 to -O2 with no effect.

Any help is appreciated!
View Solution
User avatar
mon2
XCore Legend
Posts: 1337
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Postby mon2 » Thu Jan 12, 2017 1:54 pm

After connecting the device to the PC (powering it up in the process) DSD either works or it doesn't.


Hi. Not able to offer any comments on the audio related code but can you confirm that your design will sometimes power up ok and work correctly exactly like the XMOS board you used as a reference ? That is, no hiss, etc.

If yes and you are using the same XMOS firmware then review the power and reset circuits which may be the root cause. Feel free to post the power & reset portions of your schematic for a review.
kasemann
Member
Posts: 11
Joined: Tue Dec 20, 2016 4:09 pm

Postby kasemann » Thu Jan 12, 2017 2:08 pm

Hi

thanks for the answer. The device is ALWAYS powering up and working well (except the native DSD stuff). In other words: Everytime I plug the device into the USB port I can perfectly use it as an USB audio device without hiss or click. Only the recognition of native DSD files is flawed.

I checked with our electronics guy anyway - because I admit it sounds like some sort of start-up timing problem. Our design is pretty close to the eval design but not identical. In the eval the NReset is delayed by some time, our NReset is fed by the POWER_GOOD pin of the DC/DC-converter which might be faster. I will read into the datasheet to see if there might be a problem with that.

But still: It sounds awkward to me that in case of an early NReset activation everything should start-up and run fine except DSD - I'd expect a total failure in this case.
User avatar
mon2
XCore Legend
Posts: 1337
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Postby mon2 » Thu Jan 12, 2017 2:26 pm

If the DSD support works even a single time on your board then continue to review the hardware before ruling out as the issue.

Which power rail is the dc-dc convertor supplying to release the #RESET line of the XMOS CPU ?

The XMOS datasheet notes that you should release #RESET only after the 1v0 rail is deemed to be stable. Please confirm this detail.

Also, RESET supervisors contain an inherent delay AFTER the voltage rail being monitored is deemed to be stable. For example, the ADM1085 supervisor features a capacitor defined delay.

Worth a review to confirm the delay values between the 2 boards.

If you whip up say the USB CDC example and select your CPU as the target - will your assembled custom board power up and operate as a USB CDC device each and every time ? Appears that your USB interface is solid.

Other areas to investigate - what is the output of the DC-DC convertor ? Many such modules are not regulated and demand a minimum load to keep the output voltage within the range that is desirable else can overshoot from what is expected. You could apply a dummy load of an external resistor to place the required load for this dc-dc module.
kasemann
Member
Posts: 11
Joined: Tue Dec 20, 2016 4:09 pm

Postby kasemann » Thu Jan 12, 2017 3:34 pm

Hi

I checked the manual that says it needs NReset low for 1ms after VDDIO is stable. On our board we derive VDD (1.0V core) from VDDIO after VDDIO is stable. According to my osscilloscope, VDD needs approx. 2ms to stabilize. We use the VDD_good signal of the converter to set NReset - so this should be more than 1ms after VDDIO.

To be on the safe side I implemented a quick hack: I soldered a 1uF capacitor from NReset to ground - now the NReset takes about 10ms to reach high level. The result is the same: Sometime DSD works, sometimes it doesn't.

BUT: I noticed another thing: Whenever DSD is working, the playback of the other files (non-DSD) is louder - I realized only now, because I have the ear-phones lying on the desk and not in my ears after once booming full-scale noise into my ears when trying DSD :)

That, too sounds like a power-problem but what makes me curious is: If DSD is not working, it is because inside the XMOS chip the DSD is not recognized. I verfied that the function to reprogram the PLL and the DAC for DSD is never called. So it is not a problem of the DAC or a power problem related to that...
User avatar
mon2
XCore Legend
Posts: 1337
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Postby mon2 » Thu Jan 12, 2017 5:12 pm

If DSD is not working, it is because inside the XMOS chip the DSD is not recognized. I verified that the function to reprogram the PLL and the DAC for DSD is never called.


Sounding like a h/w issue. The XMOS CPU is not being powered up correctly. So in theory, you should also be able to insert a simple LED blinky program that may or may not power up and blink the LED ?

Which PLL are you using ? The recommended factory programmed PLL from SiLabs ? This PLL should offer the proper XMOS CPU clock upon power up without any support from the XMOS CPU. Confirm that the XMOS CPU clock from the SiLabs PLL is the correct value when the DSD feature does not function.

What style of output is present on the Power_Good of the dc-dc convertor ? If open drain, which are very common, be sure there is a pull-up to define a logic high. Remove the external cap on the #RESET line and confirm there is a pull-up on the same pin. That is, till the power rails are stable, the #RESET pin on the XMOS CPU will remain parked at LOW. After 1v0 rail is stable, the #RESET will be pulled to a high.

Are the power rails supporting of the respective current draw ?

Will help if you can post the power supply and power sequencing portion of your schematic.
kasemann
Member
Posts: 11
Joined: Tue Dec 20, 2016 4:09 pm

Postby kasemann » Thu Jan 12, 2017 5:19 pm

Power lines look good to me - also the NReset really is low before being drawn to 3.3V - that is with and without the capacitor... I attached the power converter schematics below. Coming from the left is the USB power supply.
Attachments
power_supply.png
USB Power is coming from the left...
(39.85 KiB) Not downloaded yet
power_supply.png
USB Power is coming from the left...
(39.85 KiB) Not downloaded yet
User avatar
mon2
XCore Legend
Posts: 1337
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Postby mon2 » Thu Jan 12, 2017 5:34 pm

Thanks for the schematic post.

Not in agreement on why the 3v3A rail is being enabled by the 1v0 power good line. Where does this 3v3A rail connect to in your design ?

Can you consider to test as follows ?

Mate the EN to the input of this 3v3A regulator so it is powered up at the same time as the top 3v3 regulator.

Continue to use the 1v0 rail power good to reset the XMOS CPU.

R403 & R409 are very weak @ 200k for the power good pull-ups. Consider a 10k-47k value if still an issue.
kasemann
Member
Posts: 11
Joined: Tue Dec 20, 2016 4:09 pm

Postby kasemann » Thu Jan 12, 2017 5:54 pm

Hello - I just recovered from crouching on the floor banging my head on the chair...

So I found out what caused such inexplicable phenomena... There is still some sort of USB communication problem and also some sort of foobar windows problem that I don't understand, but it comes down to this:

SOMETIMES the windows master audio is set to 100 when the device is plugged in, SOMETIMES it is set to some former value lower than that. Why I don't know. But even then this should not be a problem, but for some other reason that I do not understand, this Windows master volume slider has an effect on audio even though I use the DSD ASIO driver in foobar.

The result is that whenever the windows master volume is not 100, normal files are played with less volume and DSD is rendered to some sort of rubbish.

I am sorry for wasting your time!

STILL: One thing remains - the version I compiled using the 6.15 USB audio framework produces only noise with DSD even at Windows Master Volume = 100, the version I compiled with the 6.12 framework works.
User avatar
mon2
XCore Legend
Posts: 1337
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Postby mon2 » Thu Jan 12, 2017 6:00 pm

The result is that whenever the windows master volume is not 100, normal files are played with less volume and DSD is rendered to some sort of rubbish.

I am sorry for wasting your time!


No worries. Glad to know there is a logical resolution. Perhaps someone from XMOS can offer comments on the code differences.

Be sure that the 3v3A is not linked to the XMOS device because the 3v3 rails should be powered up before the 1v0 rail. That is our understanding. The way the schematic is drawn, the 3v3 rail will be first -> the 1v0 rail will be 2nd -> the #RESET will go high & the 3v3A rail will be enabled. Not sure if this sequence is what you are after.

Who is online

Users browsing this forum: No registered users and 31 guests