AD1939 bit shift problem

Hello all,

I have a question about the AD1939.

We connected the AD1939 to a microcontroller. Normally it's working all fine but sometimes (ca. 1 of out of 10 resets), we have a bitshift in our Audio data of always one bit. When reading back the registers in the error case all is good. We have the VCC_CODEC signal under microcontroller control, hence we're able to power the chip and we can also control the AD19396_RST pin to reset the analog part of the chip. But a lot of trial and error tests with various reset sequences and delays did not bring any improvement.

The error is happening when doing a power up reset of the whole board but also when doing resets over the watchdog.

Our design is derived from the AD1939 evaluation board but we changed two things:

1) PLL Reference is MCLK, not LRCLK
2) On-chip regulator is not used, the analog part is supplied by an external source.
We would be very grateful for any hint or tip.
best regards
Matthias
Parents
  • Hello Dave,

    thanks for the quick response, here are some pictures.

    best regards

    Matthias

  • 0
    •  Analog Employees 
    on Jul 28, 2021 5:43 PM in reply to ingdb

    Hello Mathias,

    I am not certain but I think you have a ground plane on an internal layer? That is good. I think you also may have a power layer but I am not as certain since you are connecting the AVDD pins with traces. 

    It is difficult to explain all of this in writing on a post so I will try to keep it to concepts. 

    First, all bypass caps need to be on the top layer. For example C40 and C42 are on the bottom. This makes them very ineffective at filtering out high frequency noise from things like clocks because the vias are inductive. 

    The power needs to be on a layer like the ground layer but the power can often be a split layer for the different power rails. It can get a bit tricky to make it work but make the attempt. 

    Then the traces between the caps and the pins need to be short and the vias to the power layer need to be on the far side of the caps. Like this:

    Do not make any connections from the pins to other pins on the part. The connections you see should be all that there is. Power and ground come from the layers below so any noise from the part is filtered by the cap before it gets to the plane and likewise, the noise from the plane is filtered out by the cap before it gets to the part. It works both ways. 

    You did well to have the loop filter close to the AVDD and LF pins. The only detail is that I do not see any bypass cap on that AVDD pin but the layout is rather crowded. Those loop filter parts also need to stay on the top layer like you have them. By the way, I know that some of this will be difficult to do because your layout is very compact.  

    The trace on the AVDD from pin 62 to the other AVDD pins needs to be cut and use a power plane of some sort with pin 62 well bypassed. That AVDD pin powers up the PLL so you need to give it special attention. I have seen many designs where they use an inductor and cap of its own to feed just that pin. This is what may be causing your issues. The AVDD and DVDD are shared and you may be getting noise from DVDD causing locking issues with the PLL. The DVDD bypass caps being on the bottom of the PCB makes them do no good at all. 

    Never populate L11. It is connected to the AVDD and the only way it can get to the DVDD pins is through two more inductors. L11 should be connected to the same place that the other inductors are getting their AVDD voltage. But then you would not need L11 you would only need to put in a jumper because the other inductors will do the job. 

    You should also have a 10uf cap on the DVDD side of L10. It can be on the bottom of the PCB. 

    I am also assuming you are not putting in a ground fill on the top layer? If you are you need to be certain that it does not connect to any of the ground pins on the part. Let the part get its ground only through the vias on the far side of the caps. The top ground fill should have its own vias to the ground plane. 

    Dave T

  • Hello Dave,

    thanks for these tips, we will consider it in the next release. But we did a test with the AD1939 eval board and we're having the same bitshift. Its happening when using the interal LDO of the AD1939 and when using an external LDO. So it looks as if its not a design problem?

    regards

    Matthias

Reply Children
  • 0
    •  Analog Employees 
    on Aug 9, 2021 7:41 PM in reply to ingdb

    Hello Matthias,

    This is not anything we have ever seen here using the part with the eval board or in testing the part. The part is one of our most popular parts and has been designed into many automotive applications where it was tested heavily and this issue has not been seen except for the times where there was PCB layout issues. Now the layout of the eval board is not the best since it was done a long time ago before some of these layout issues were better understood. 

    I would like to ask you a few more questions to see if it might be something else. 

    What serial format are you using?

    Sampling rate?

    Size of the entire channel slot?

    Number of bits for each channel?

    Left justified or delayed by one bit?

    Dave T

  • Hello Dave,

    I got your point, it's really strange. Here is some more info:

    What serial format are you using?

    A:

    Sampling rate?

    A: 48kHz

    Size of the entire channel slot?

    A: 2x channels 64 BCLK's per frame

    Number of bits for each channel?:

    A: 32 bits but data word is 16 bit

    Left justified or delayed by one bit?

    SDATA delay (BCLK periods) 1

    Just forward them the configuration
    //wwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww
    // write AD1939 config
    // - ADC and DAC channels configured in master mode LR & BCLK
    // -
    //--------------------------------------------------------------------------
    // 1. PLL and Clock Control 0 Register
    // - power down PLL
    // - MCLK output disabled
    // - disable DAC and ADC
    txSPI(AD1939_ADDR, AD1939_REG_PLL_CLK_CTRL0, 0x19);

    // 2. PLL and Clock Control 1 Register
    // - DAC clk source PLL clk
    // - ADC clk source PLL clk
    // - on chip voltage reference enabled
    txSPI(AD1939_ADDR, AD1939_REG_PLL_CLK_CTRL1, 0x00);

    // 3. DAC Control 0 Register
    // - power down normal
    // - sample rate 48 kHz
    // - SDATA delay 1 sample
    // - stero mode
    txSPI(AD1939_ADDR, AD1939_REG_DAC_CTRL0, 0x00);

    // 4. DAC Control 1 Register
    // - latch in at the end of cycle
    // - 2x channels 64 BCLK's per frame
    // - LRCLK low for left channel
    // - LRCLK master mode
    // - BCLK master mode
    // - BCLK polarity inverted
    txSPI(AD1939_ADDR, AD1939_REG_DAC_CTRL1, 0x71);

    // 5. DAC Control 2 Register
    // - master mute -> unmute
    // - flat mode
    // - 16 bit resolution
    // - DAC output non-inverted
    txSPI(AD1939_ADDR, AD1939_REG_DAC_CTRL2, 0x18);

    // 6. DAC Individual Channel Mutes
    // DAC1 left unmute
    // DAC1 right unmute
    // DAC2 left unmute
    // DAC2 right unmute
    // DAC3 left unmute
    // DAC3 right unmute
    // DAC4 left unmute
    // DAC4 right unmute
    txSPI(AD1939_ADDR, AD1939_REG_DAC_CHANNEL, 0x00);

    // 7. DAC Volume Controls
    // each register coresponds each DAC channel and its set based on function
    // passed value vol!
    txSPI(AD1939_ADDR, AD1939_REG_DAC_L1_VOLUME, vol);
    txSPI(AD1939_ADDR, AD1939_REG_DAC_R1_VOLUME, vol);
    txSPI(AD1939_ADDR, AD1939_REG_DAC_L2_VOLUME, vol);
    txSPI(AD1939_ADDR, AD1939_REG_DAC_R2_VOLUME, vol);
    txSPI(AD1939_ADDR, AD1939_REG_DAC_L3_VOLUME, vol);
    txSPI(AD1939_ADDR, AD1939_REG_DAC_R3_VOLUME, vol);
    txSPI(AD1939_ADDR, AD1939_REG_DAC_L4_VOLUME, vol);
    txSPI(AD1939_ADDR, AD1939_REG_DAC_R4_VOLUME, vol);

    // 8. ADC Control 0 Register
    // - normal mode for power down
    // - high pass filter ON
    // - unmute all 4x ADC channels
    // - output sample rate 48 kHz
    txSPI(AD1939_ADDR, AD1939_REG_ADC_CTRL0, 0x02);

    // 9. ADC Control 1 Register
    // - 16 bit data samples
    // - SDATA delay 1 BCLK sample
    // - stero mode
    // - Latch in the middle of the cycle
    txSPI(AD1939_ADDR, AD1939_REG_ADC_CTRL1, 0x03);

    // 10. ADC Control 2 Register
    // - LRCLK format 50%/50%
    // - BCLK polarity drive out on falling edge
    // - Master mode
    // - 64x BCLK's per frame
    // - BCLK master mode
    // - BCLK source PLL
    txSPI(AD1939_ADDR, AD1939_REG_ADC_CTRL2, 0xC8);
         
       
        //// disable DAC & ADC then enable it
        txSPI(AD1939_ADDR, AD1939_REG_PLL_CLK_CTRL0, 0x01);
        delay_ms(100);
    txSPI(AD1939_ADDR, AD1939_REG_PLL_CLK_CTRL0, 0x80);
        
    regards
    Matthias
  • 0
    •  Analog Employees 
    on Aug 11, 2021 7:25 PM in reply to ingdb

    Hello Matthias, 

    Thanks for keeping this conversation going. It is a bit strange. I was hoping to see if you were accidentally placing the part into Standalone mode but for the most part the setup you are using is the same as the Standalone mode. What I was looking for is if you were setting it up for no delay of the bit clock then when it goes into standalone mode it would change to one BCLK delay but I am not seeing that. So I do not have any ideas at the moment as to what is causing what you are seeing. 

    Standalone mode can be entered at any time if CIN, CCLK, CLATCH are held low for around 3-5ms. So if there is an issue with SPI comms where the controller is interrupted when CLATCH is low and the clock and data happen to be low as well then it will enter standalone mode. It can happen at any time not just during configuration. You cannot tell it is in that mode with any reads to any register and the only way to get out of the mode is to reset the part. This is why we recommend a pull up on the CLTACH to cover the time when the controller is booting up and the pin might be low. But as I said, I do not think this is happening in your case.  

    The only thing I see here that is a little odd is that you are latching the DAC data at the end of the cycle instead of the middle. But this probably is not the cause but depending on Signal Integrity it might cause the bits to be off by one. 

    So this brings up the question that when you said one bit was off, were you looking at the captured data in the system or were you actually looking at the I2S waveforms on a scope?

    Dave T