Issue with Audio DAC (PCM1681) - Page 1
Forum section: electronics / projects

author: Saimoun
author_rank: Frequent Contributor
timestamp: September 11, 2020, 01:06:41 pm
content: HiI am trying to get an 8-channel audio DAC to work. It's a TI PCM1681 (datasheet:https://www.ti.com/lit/ds/symlink/pcm1681.pdf). It's not the first time where I just cannot get a chip to work (at all), but the issues I had before were soldering based (I am pretty sure), and this DAC comes in a 28-TSSOP package which was not too hard to solder on the PCB.The circuit is super simple: the chip is mounted on a PCB with a few bypass caps and a stereo audio output circuit (which for now I am not using - probing directly at the ouputs of the DAC). The PCB is then on a breadboard where I have breadboard wires connecting it to my STM32 Nucleo-F446RE board where the MCU is.The MCU sends the digital audio data using 2 data lines + clocks (TDM format) and controls the chip over an I2C line. On the breadboard I added 2 pullup resistors (4.7k) for the I2C lines.The errors I get are:The outputs are meant to be at Vcom=Vcc/2 (2.5V) when no audio is sent, but they are around 0.4V, and 0V when I sent audio (I probed the Vcom pin and it reads 0.4V which makes sense - I did it quickly because my experience is these pins do not like loads, even a very small load like my oscilloscope probes)Sometimes the I2C stops working (the pins start moving strangely between 0V and 3.3V like if they were floating) - but most of the time it worksWhat I have checked:The chip is genuine TI from DigiKeyI know the datasheet inside out by now and I am pretty sure the design itself is correctI do not have any ESD equipment but I was super careful about it and watching a few videos on the subject where people test it I can see you need a decent amount to actually blow a chip. And the chip has basic ESD protection.After solering I took my multimeter in "beeping" mode to check: (1) no shorts between adjacents pins and (2) probing on top of each pin to make sure they were actually connected to the PCBBefore even using the PCB board at all - I wrote some code for the MCU and tested both the digital audio lines and the I2C lines - they both work like they should.Using a logic analyzer I could see the I2C messages which all look fine. The only register value I change from the MCU is the FMT[3:0] to set the DAC in TDM mode. I checked the contents of all the registers of the DAC from the I2C, and they fits their default values (apart from 0x09 which is 0x06 - i.e. TDM mode):Code:ADRBit7Bit6Bit5Bit4Bit3Bit2Bit1Bit0Default Value----0x01AT17AT16AT15AT14AT13AT12AT11AT100xFF0x02AT27AT26AT25AT24AT23AT22AT21AT200xFF0x03AT37AT36AT35AT34AT33AT32AT31AT300xFF0x04AT47AT46AT45AT44AT43AT42AT41AT400xFF0x05AT57AT56AT55AT54AT53AT52AT51AT500xFF0x06AT67AT66AT65AT64AT63AT62AT61AT600xFF0x07MUT8MUT7MUT6MUT5MUT4MUT3MUT2MUT10x000x08DAC8DAC7DAC6DAC5DAC4DAC3DAC2DAC10x000x0900FLT0FMT3FMT2FMT1FMT00x050x0ASRSTZREVDREVDMF1DMF000DMC0x000x0BREV8REV7REV6REV5REV4REV3REV2REV10xFF0x0COVER000FLT4FLT3FLT2FLT10x0F0x0DDAMSAZRO1AZRO0000000x000x0EZERO8ZERO7ZERO6ZERO5ZERO4ZERO3ZERO2ZERO1N/A0x10AT77AT76AT75AT74AT73AT72AT71AT700xFF0x11AT87AT86AT85AT84AT83AT82AT81AT800xFF0x12000000MUT8MUT70x000x13000000DAC8DAC70x00AT = attenuation, default is max volume = 255 (0dB), min volume is 129 which is -63dB, below 129 is mutedMUT = soft mute (disabled by default)DAC = enable DAC (enabled by default)FMT = serial data format (0110 for I2S TDM 24bit, default 0101)DMF = de-emphasis (disabled by default)DREV/REV = phase reverse (DREV disabled by default, all REVx enabled by default)I have a few ideas about what could be wrong:Somehow the chip got damaged during soldering? I was very quick with the iron and never stayed on a pin more than 1-2 seconds. As you can see on the picture there is no excess solder either. (yes I use this "spider-shaped" shape pads to help me solder - I know people told me not to do that but that was after I ordered these test boards - but if you are really convinced that is the problem I can order new PCBs without itThe master clock line of the serial audio data is at 10Mhz - that is faster than any signal I have worked with before - maybe the signal integrity is not that good? My oscilloscope is not that great (Analog Discovery - not fast enough to see the clock edge) but the logic analyzer was able to see the digital 0's and 1's.Maybe it's not really possible to test this chip with this setup - i.e. I need to design a PCB with the MCU and the chip (on the same board)?I apologise for the long post - hope it did not scare you off - but there is no point asking for help if I do not show everything I have done so far.Thank you in advance for any helpCheersSimon

author: Saimoun
author_rank: Frequent Contributor
timestamp: September 11, 2020, 01:09:38 pm
content: A few pictures:

author: capt bullshot
author_rank: Super Contributor
timestamp: September 11, 2020, 01:25:42 pm
content: My guess could be wrong, of course, but your setup doesn't look good enough for a possibly fast edge clock (MCLK) signal.- Set the pin drivers of the audio clock and data lines to the slowest working setting at the STM32 chip (not the fastest), as this reduces GND bouncing.- Make a real short and low impedance GND connection from the nucleo to the DAC board, put them as near together as possible. Don't use the breadboard and place the PCBs directly adjacent so you can solder one (or more) very short wire(s) to connect their GND planes.- Use as short as possible wires to route the audio CLK and data signals (don't use the dupont wires, cut them to length and solder 'em)- do you have proper pull-up resistors at the I2C lines (external 4k7 or the like, not just the internal pull-ups)?

author: Saimoun
author_rank: Frequent Contributor
timestamp: September 11, 2020, 01:58:41 pm
content: Thanks that was actually one of my first ideas! But how would that explain the strange voltages on the output pin and the Vcom not at Vcc/2?(my guess: without a Master clock the chip cannot function correctly)Yes I have external 4.7k pullup for the I2C line - I also run it super slow at 10kHz to avoid any issues on it.I'll try to solder everything and run the serial audio slower (that would be 2MHz with 8kHz audio - I do not know if the DAC chip could go slower?).

author: capt bullshot
author_rank: Super Contributor
timestamp: September 11, 2020, 05:49:11 pm
content: Quote from: simonlasnier on September 11, 2020, 01:58:41 pmDidn't read the datasheet, maybe the Vcom is programmable through I2C?

author: mck1117
author_rank: Contributor
timestamp: September 12, 2020, 05:05:19 am
content: Quote from: capt bullshot on September 11, 2020, 05:49:11 pmNope. It's referred to in the datasheet multiple times as buffered Vcc/2.During the reset period, the DAC output is forced to Vcom, so if that's not the case, then something is wrong with the board/chip. Have you tried removing the 10uF decoupling cap on Vcom, C5?

author: Saimoun
author_rank: Frequent Contributor
timestamp: September 12, 2020, 10:06:02 am
content: Yes that is true - would then this a be a valid test to see if the chip is damaged to:* Connect all digital lines to GND (MCLK/SCK, BCLK, DATA1-4)* Apart from the I2C lines (SCL, SDA) which I pullup to 3.3V* Simply give it 5V on VCC and 3.3V on VDD* Measure the analog output levels?As I understood the chip should stay in reset until it gets 65536 clocks on the MCLK/SCK line - is that correctly understood?And @capt bullshot -> I am still trying what you suggested, I slowed down the SCK to 2MHz and sent 8kHz audio (a 500Hz sine wave on all 8 channels) this I could check with the oscilloscope it is way within the requirements - even on the breadboard. I also checked the SDA/SCL rise/fall time which is also within specs.The results is still the same - kinda getting worse though, the I2C interface fails about half of the time now (but the other half everything looks fine and I get the correct values from the registers). Not sure how to investigate this - maybe one of the SDA/SCL line is half dead?I have not tried soldering everything yet like you said but I will

author: Saimoun
author_rank: Frequent Contributor
timestamp: September 12, 2020, 11:45:30 am
content: Ok I did a test where:* SDA/SCL pull up to 3.3V - so that everything stays in default mode* All digital lines to GND apart from the MCLK that I drive from the MCU* 5V on VCC and 3.3.V on VDD* Removed the C5 capacitor (on the Vcom pin)* soldered wire from GND to my MCU's GND* soldered wire from MCLK to my MCU's MCLK output, with a 33Ohm resistor in series* measured the analog output 1This gives the following:

author: Saimoun
author_rank: Frequent Contributor
timestamp: September 12, 2020, 11:52:47 am
content: Precisely the same test with a brand new 10uF electrolytic capacitor on the Vcom pin. This looks like the chip does not like the capacitor, maybe the ESR or something like that? The datasheet does not say a thing about the Vcom cap, apart from the fact that it should be 10uF...

author: Bassman59
author_rank: Super Contributor
timestamp: September 12, 2020, 06:26:34 pm
content: Quote from: simonlasnier on September 12, 2020, 10:06:02 amA couple of things.First, verify -- and if this means getting a better 'scope, then so be it -- that your BCLK, LRCK and data lines are all synchronous with the system clock.Next, make sure that you're actually sending the data in the correct format. You said you are sending TDM data, so verify that the signals are all correct.Verify that the chip is configured to accept TDM input. (In hardware config mode, that means FMT bits both high.)

author: dietert1
author_rank: Super Contributor
timestamp: September 12, 2020, 07:52:53 pm
content: Maybe an overheating issue? I remember an audio project with a PCM1690 and i think it had a power pad that was to be used for cooling. Even when that pad was used the chip got hot.Regards, Dieter

author: floobydust
author_rank: Super Contributor
timestamp: September 12, 2020, 08:52:19 pm
content: You must have 1/2VCC at the VCOM pin. If you don't... then check those pcb traces and C5, that no analog output channels are shorted to GND or have failed. You can use ohms or diode test to check them each, with power off.You have to be careful of power on/off sequence, some IC's don't like one rail coming up before the other i.e. 3.3VDD first then 5VCC, without latch-up.I don't know your whole schematic but the output decoupling capacitors can damage the IC if they discharge fast i.e. brief short with probe.

author: Saimoun
author_rank: Frequent Contributor
timestamp: September 12, 2020, 08:54:18 pm
content: @Bassman59 -> thanks for the suggestions. I did check all the digital lines with a logic analyzer before and everything is where it should be, I even checked the actual data which was correct. Looking at scope the clocks are in sync and the waveforms do not look too bad (or maybe they do - you tell me?)See below:* picture 1: yellow=MCLK, blue=BCLK* picture 2: yellow=MCLK, blue=LRCLKEDIT: and yes the chip is configured in TDM - I tried both using the hardware and the I2C mode (from the I2C I can read register 9 which contains 0x06 which confirms that the chip accepted the change and is in TDM mode).

author: Saimoun
author_rank: Frequent Contributor
timestamp: September 12, 2020, 09:07:25 pm
content: @dietert1 -> I thought about overheating - the datasheet says it is not necessary to solder the power pad. Also the chip itself really does not get hot at all.Quote from: floobydust on September 12, 2020, 08:52:19 pmAt this point I am pretty sure the chip is dead. I am happy to start over with a fresh PCB and a fresh chip, but I wanted to hear stuff like that so I do not end up again in the same situation. So when I do solder a new chip on a new PCB, what do you think I should test? Here is what I usually test:1) That no pin is shorted to the ones next to it (using ohms meter in "beeping" mode)2) That each pin of the IC is actually connected to the PCB (same)3) That there is no short between any of the rails and GND (same)4) I can add a test to make sure none of the analog outputs of Vcom is shorted to GND5) Anything else?And about the 5V/3.3V rails they both come from my Nucleo, I just checked with my oscilloscope and the 3.3V comes 50us later than the 5V (makes sense since the 5V is from the USB) - that should be ok I think? Nothing is mentioned on the datasheet about the rails.

author: lordkex
author_rank: Newbie
timestamp: November 28, 2024, 03:58:05 pm
content: I hope you are still active on the forum...Have you managed to figure out the issue? I am facing the same problem...

author: lordkex
author_rank: Newbie
timestamp: December 02, 2024, 06:47:08 pm
content: Well, I solved it....The solution was rather easy, use the frikking Transmit_DMA function as it is intended and set the length of the buffer correctly