ΣSigmaStudio Ask AI Русский Log in

ADAU1701 - Sample Rate Issues

SigmaDSP & SigmaStudio eepmc May 19, 2016 00:00 7 replies Original on forum ↗
Subscribe
eepmc Question
May 19, 2016 00:00

Hi,

I am just prototyping a board with the ADAU1701 and have some strange issues regarding audio not being the correct frequency, probably related to wrong sample rates somewhere.

The set up is as follows:

Crystal = 12.288Mhz

PLL= set for 64Fs

Program set to 2x length (96kHz operation)

Sigma DSP project blocks set to 96kHz

When I use the tone generator in SigmaDSP to send a 1kHz tone to the DACs, the measured output is at 250Hz. Obviously something is wrong and the fact that it is exactly 1/4 of the frequency seems like a setting is wrong somewhere.

Thanks

Audio Signal Processors

sample rate

SigmaDSP Audio Processors

adau1701

KJBob Reply
May 19, 2016 00:00

Hello,

The short answer is, Set your PLL mode to "256 x Fs" -- that is, PLL_MODE_0 low, and PLL_MODE_1 high -- and you'll be operating correctly.

What the PLL really does is derive the 49.152 MHz core clock from the crystal. Since the ADAU1701 is a 50 MIPS part, the core clock always runs at either 49.152 MHz (for 48 / 96 / 192K sample rates) or 45.16 MHz (for 44.1 KHz and its multiples). The datasheet unfortunately confuses things a bit by involving the sample rate rather than the core clock in its descriptions.

This is better explained at: Setting the PLL mode for the ADAU1701 at different sample rates

Best regards,

Bob

eepmc Reply
May 20, 2016 00:00

Hi Bob,

Thanks for your reply. Unfortunately I have realised that there was a mistake in my original post: I do already have it set for 256Fs with PLL_0 low and PLL_1 high, not 64Fs. Do you have any other suggestions?

Thanks

KJBob Reply
May 20, 2016 00:00

Hello,

With your PLL set correctly, here's a few other possibilities:

If the tone generator you mentioned above is part of an extensive project, try a test with just the tone generator and the DACs. If your present project uses more than about 500 instructions, it can't run at 96K. The Sigma100 (1701, etc.) compiler only reports a "Ran out of MIPS" error when exceeding the larger 48 KHz limit; however the project won't run properly. This reference describes how to check your instruction usage: https://ez.analog.com/message/78183#comment-78183

How are you booting your -1701 -- directly from Sigmastudio via USBi, via a microcontroller, or via self-boot? There could be an issue with for example, the boot sequence as written in your uC code.

If you haven't already, scope the crystal to see if it's actually oscillating at 12.288 MHz. If MP11 is available on your board, you can set it as a BCLK Master output and measure its frequency to check the PLL operation -- see page 18 of the ADAU1701 datasheet.

If a basic tone generator + DAC project still fails, please attach it and I'll try it on a stock -1701 eval board to check the settings.

Best regards,

Bob

eepmc Reply
May 27, 2016 00:00

Hi Bob,

Thanks again for your help. As I am still verifying the board it is a very simple project with really just the signal generator and a few GPIOs to flash LEDs, so I don't think the issue is MIPs related. Also the board is running either directly from USBi or self boot from EEPROM.

Good suggestion on the BCLK, I tried measuring it and it does indeed seem to be at only 1/4 of the correct frequency. Luckily I also have an Elektor ADAU1701 board which I can compare it against with the same project (which is all working correctly).

So I suspect that the PLL is running at 64Fs instead of 256Fs. I definitely have my jumpers set so PLL_0 is low and PLL_1 is high, I think the cause must be a bad solder joint on the ADAU1701's PLL pins (the chip was soldered by hand).

Thanks

Elliott

eepmc Reply
May 27, 2016 00:00

Strange....I have just reflowed it and measured directly on the pin of the DSP. PLL_0 is definitely 0V and PLL_1 is definitely 3.3V.

Do you have any other suggestions?

Elliott

eepmc Reply
May 27, 2016 00:00

I have solved it

On my application board the RSVD pin (30) was incorrectly tied high instead of low. After correcting the error the board now outputs the correct frequency

Thanks

Elliott

KJBob Reply
May 27, 2016 00:00

Hello Elliott,

Congrats on getting your board working. That's quite a "gotcha" you found!

Bob