cancel
Showing results for 
Search instead for 
Did you mean: 

STM32 -> ADAU1701

marcdraco
Associate II

I'm finalising a design with an AD1701 using the STM32 as the USB-audio driver (it's a modular, mix and match design but the STM32 is the most appropriate for the "reference design".

And herein is the issue, for a decent sample rate of 48 or 96 KHz (not audiophile but good enough) an accurate master clock running at 12,288 MHz which I can't get from the 1701 and in any case throwing that sort of frequency down jumpers is likely to end up in the board getting hoisted by a few kilograms of a home-made petard.

CubeMX calculates the error as high as 1.72% for 96 KHz for example with a 25 Mhz HS clock input. 

I'm a little confused (I hail from the days when CPUs ran at 4-8MHz and we thought they were fast) so it might be my age but I don't understand how to correct this sort of error. I'd appreciate if someone more knowledgeable about I2S (or the SAI peripherals) of how to best ameliorate this issue.

I know how PLLs work to lock onto a signal but I'm out of my depth (I'm primarily a writer and design is largely a hobby for my own education). Mostly I'm confused on what effect the error will have on the recorded audio. I wonder if I'd be better of generating a 12.288 MHz from a simple Xtal oscillator using a Pierce oscillator and be done with it?

At least I can control both devices from a single master but I'm honestly baffled what this clock drift does.


1 ACCEPTED SOLUTION

Accepted Solutions

>Suggestions welcome and anyone who can help solve this 

So i try....  (seems you didnt build something like this, so problems first):

1. if you want a standard USB (UAC1 , 48kHz, 16b, stereo/2 ch ) codec interface (AD in + DA out ), you have to deal with the clock : master is the PC, so your device has to get its clock by a PLL from the 1ms timing on the USB bus.

DAC only is no problem , PCM5102 can do this (internal PLL); but ADC...i dont know.

2. to see, what you can do on the software , to get it enumerated as standard audio interface in Win, Linux or Mac, buy a cheap board with the target cpu you want and try to get a working software on it;

board should be with debug interface, so i recommend: a nucleo board, with USB .

cheapest maybe : NUCLEO-H533RE , 13,64 € at Digikey (next week avail.) - or anywhere.

or NUCLEO-H753ZI or NUCLEO-H563ZI   , about 25 € .

3. use theSTM32CubeIDE  , generate a design with the cpu you want to do it, then set it to I2S in/out and the USB to device -> audio . Then try to start compiler and make a program....if it looks good, you ready to buy a board with these cpu and test it for real.

If you feel a post has answered your question, please click "Accept as Solution".

View solution in original post

5 REPLIES 5
Pavel A.
Super User

Here you can find professional help for your STM32 project. 

 

Thanks Pavel, I'm familiar with Fiver but as an Open Source developer, part of the job is "learning on the job" - I do this for my own enlightenment and education. It's nostalgic - at least it would be if these things didn't run like a rocket-powered cheetah. But I do enjoy getting my hands dirty again - from design to final product. The big difference now is my PCBs at least look like some thought went into them.

I may well have to hire someone to get the STMF7 to act as a composite USB device, since that's totally beyond me. USB simple on the outside but a nightmare on the inside, amirite?

I've figured the best solution [at least to the master clock] is to use a simple Schmitt inverter with a 12.288 MHz crystal and use a couple of buffers to supply the master clock to both devices simultaneously.  On of the spares might come in handy as a short reset monostable too. This seems to be a better solution so I can use any one of several STM32 MCUs without too much trouble, The 1701 might be able to output a master clock (I haven't looked that close) but using the same central clock for both devices should eliminate jitter and keep everything in concert, even if the USB drifts - we all have to suffer that.

Course designing a reliable Pierce oscillator looks deceptively simple, I'm going to have to dig in a bit to make sure this thing works first time (every time). 

Looks like an alternative (though potentially "hidden rake" option would be to buffer the sine wave from the 1701's xtal with a Schmitt buffer (available in SOT23-5 so potential if I run low on board space. 

I'm still in the dark about the sampling and internal clocks where I2S is concerned so if anyone is able to help, solutions gratefully received with thanks.

Hi,

maybe good, if you tell (me) , what you want to build - generally fundamentally : an audio player ? 

or a USB sound card with some DSP processing inside ?

1701 ...is ADAU1701 ?  ( i assume) + cpu is ..?

btw

I made an audio player with H743 and ES9038 DAC (and other dacs...), plays from SD-card and USB.

If you feel a post has answered your question, please click "Accept as Solution".
Essentially a USB sound card, yes but a little more generic and expandable than the usual fair. Actually, a 1701 isn't a prerequisite, it could be any 16, 24 or 32 bit ADC so long as it doesn't exceed the speed. What matters most is an MCU to accept the I2S signals from "XYZ" device and send them to the PC via USB. Essentially a USB-audio device emulation.

I've got most of it down, where I'm lost is in the synchronisation issue when the two clocks are slightly adrift. 12.288MHz isn't difficult to synthesise, but shovelling such a high speed clock through pin-headers/pin-sockets (the STM board, ideally, needs to be a pluggable module so it can be replaced, upgraded with a better one, etc) is going to be prone to reflections where the tracks switch through the 90 degree turns. Excuse my "language" but I could foresee someone wanting to use something like a RPi (Pico, 3, 4, etc.) so the design has to be as "generic" as possible, supporting at the very least official dev boards and some limited ability to accept some that don't follow the same pin-out on their headers.

I want it as modular as possible for my own restricted budget too - if I mess something up (which is quite plausible) then I've wasted not just the 1701 but also the STM32F7. Analog Devices' own dev-kit has a very suspect Master Clock select with a switch no less and a pin-socket to accept an incoming master clock. This might be OK for prototyping but I have my doubts for reliability even under lab conditions. Trying to run a such a fast clock over even short DuPont wires is antithetical to everything I know.

A differential pair would be fine under normal circumstances but the issue is that dev-boards don't have differential receivers. I dare say it's possible to use the STM32's GPIO's to re-create the signal from a differential pair but there's the issue of cleaning the signals up before they are processed with a Schmitt trigger and we're back to square one. Using something like Ethernet (for the twisted pairs) is possible but it adds more cost and complexity.

Perhaps I'm being too pedantic but I've had reflection issues "kill" a board using just a USB FS (12 Mbit/S) line because the impedance was off a little over 20 ohms (probs. the wrong board material, but it could be the TVS stubs I'd slapped on rather thoughtlessly). Not much, but more than enough to stop it even talking. Amazing how such a simple (or sloppy) oversight can be so expensive.

The alternative is to just live with that 0.35% (48 kHz) or 1.7% (96 kHz) error rate by using the LRClock I guess, but this is where my brain squeezes out of my ears a bit. What actually happens? Is there an alternative way to generate the 12.288 master clock via the PLLs? (I can't see a way to do this in Cube but I'm new to STM32 architecture and very impressed with the dev tools.

The pure option is to forego that part of the modularity and run with an F7 on-board with the 1701 (or some alternative ADC/DAC pair). Seems to me that the F7 is probably just as capable for the limited amount of DSP processing this thing actually needs. (complex audio processing HTRF and such isn't really part of the spec, it just needs very basic mixing, inversion and level adjustment.) The choice of the F7 is largely down to what I can actually get easily from JLCPCB/LCSC that have (a) I2S and (b) are capable full-speed USB-audio. (Personally, I'd prefer to just stick the F7 on there and be done with it because that way I can feed the Master clock over a few milimeters (less than 1") of a conductor and drive it direct.)

Suggestions welcome and anyone who can help solve this will not just receive my eternal thanks but also a mention on the silkscreen in the thanks section. No man is an island, after all and I'm not claiming to be [sarcasm]Elon Musk, the world's greatest engineer[/sarcasm]. I try to know my own limits.

>Suggestions welcome and anyone who can help solve this 

So i try....  (seems you didnt build something like this, so problems first):

1. if you want a standard USB (UAC1 , 48kHz, 16b, stereo/2 ch ) codec interface (AD in + DA out ), you have to deal with the clock : master is the PC, so your device has to get its clock by a PLL from the 1ms timing on the USB bus.

DAC only is no problem , PCM5102 can do this (internal PLL); but ADC...i dont know.

2. to see, what you can do on the software , to get it enumerated as standard audio interface in Win, Linux or Mac, buy a cheap board with the target cpu you want and try to get a working software on it;

board should be with debug interface, so i recommend: a nucleo board, with USB .

cheapest maybe : NUCLEO-H533RE , 13,64 € at Digikey (next week avail.) - or anywhere.

or NUCLEO-H753ZI or NUCLEO-H563ZI   , about 25 € .

3. use theSTM32CubeIDE  , generate a design with the cpu you want to do it, then set it to I2S in/out and the USB to device -> audio . Then try to start compiler and make a program....if it looks good, you ready to buy a board with these cpu and test it for real.

If you feel a post has answered your question, please click "Accept as Solution".