This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

PCM1865: configuration or PLL issue?

Part Number: PCM1865

We have an issue where the PCM1865 on our PCA is not booting up correctly a small percentage of the time. Symptomatically the decimation filters do not appear to be configured correctly, such that low frequencies (~1khz) are represented correctly in the output data, while higher frequencies (~20khz) have significant attenuation. 

PCM1865 configuration:

Sample rate: 96ksps
Output format: I2S with 2 DOUT pins for 4 channel output
Bus details: I2S master. BCK, LRCK both driven by ADC
Input clock: 38.4MHz high quality oscillator connected to SCKI

I recorded the I2C programming sequence on my oscilloscope with serial data logging, here is the sequence with timestamps and notes:

Time Address Data Notes
-43.04us 4BW 00 FE reset
34.16us 4BW 00 00 page=0
111.3us 4BW 70 71 pwr=standby
188.3us 4BW 0B 00 fmt=i2s
265.4us 4BW 0C 00 tdm=2ch
342.4us 4BW 20 10 clk=mstr, src=sck
419.4us 4BW 21 01 dsp1_clk=38.4M/2
496.5us 4BW 22 03 dsp2_clk=38.4M/4
573.5us 4BW 23 0F adc_clk=38.4M/16
650.5us 4BW 25 03 sck_div=38.4M/4
727.6us 4BW 26 03 bck_clk=38.4M/4
804.6us 4BW 27 3F lr_clk=bck/64
881.6us 4BW 28 00 disable PLL
958.6us 4BW 29 01 PLL P=1/2
1.036ms 4BW 2A 00 PLL R=1
1.113ms 4BW 2B 05 PLL J=5
1.190ms 4BW 2C B0 PLL D = 0.12
1.267ms 4BW 2D 04 PLL D = 0.12
1.344ms 4BW 28 01 enable PLL
1.421ms 4BW 70 72 pwr=sleep
1.498ms 4BW 11 50 gpio3=dout2
1.575ms 4BW 71 30 DSP: HPF en, IIR en
1.652ms 4BW 06 50 mux adc1L=1diff
1.729ms 4BW 07 50 mux adc1R=2diff
1.806ms 4BW 08 60 mux adc2L=4diff
1.883ms 4BW 09 60 mux adc2R=3diff
1.960ms 4BW 01 28 adc1L gain=20dB
2.037ms 4BW 02 28 adc1R gain=20dB
2.115ms 4BW 03 00 adc2L gain=0dB
2.192ms 4BW 04 00 adc2R gain=0dB
2.269ms 4BW 00 00 page=0
2.346ms 4BW 20 3E clk=mstr, src=pll (98.304M). Dsp1_clk=pll_clk/2, dsp2_clk=pll_clk/4, adc_clk=pll_clk/16, bck=pll_clk/16
2.423ms 4BW 70 70 pwr=run

Afterwards, an I2C readback of all registers has 1 of 2 possible results. For a successful boot (majority of the time):

Page 0, Reg 0x01: 0x28
Page 0, Reg 0x02: 0x28
Page 0, Reg 0x03: 0x00
Page 0, Reg 0x04: 0x00
Page 0, Reg 0x05: 0x86
Page 0, Reg 0x06: 0x50
Page 0, Reg 0x07: 0x50
Page 0, Reg 0x08: 0x60
Page 0, Reg 0x09: 0x60
Page 0, Reg 0x0a: 0x00
Page 0, Reg 0x0b: 0x00
Page 0, Reg 0x0c: 0x00
Page 0, Reg 0x0d: 0x00
Page 0, Reg 0x0e: 0x00
Page 0, Reg 0x0f: 0x28
Page 0, Reg 0x10: 0x01
Page 0, Reg 0x11: 0x50
Page 0, Reg 0x12: 0x00
Page 0, Reg 0x13: 0x00
Page 0, Reg 0x14: 0x00
Page 0, Reg 0x15: 0x00
Page 0, Reg 0x16: 0x28
Page 0, Reg 0x17: 0x00
Page 0, Reg 0x18: 0x00
Page 0, Reg 0x19: 0x00
Page 0, Reg 0x1a: 0x00
Page 0, Reg 0x1b: 0x00
Page 0, Reg 0x20: 0x3e
Page 0, Reg 0x21: 0x01
Page 0, Reg 0x22: 0x03
Page 0, Reg 0x23: 0x0f
Page 0, Reg 0x25: 0x03
Page 0, Reg 0x26: 0x03
Page 0, Reg 0x27: 0x3f
Page 0, Reg 0x28: 0x01
Page 0, Reg 0x29: 0x01
Page 0, Reg 0x2a: 0x00
Page 0, Reg 0x2b: 0x05
Page 0, Reg 0x2c: 0xb0
Page 0, Reg 0x2d: 0x04
Page 0, Reg 0x30: 0x00
Page 0, Reg 0x31: 0x00
Page 0, Reg 0x32: 0x00
Page 0, Reg 0x33: 0x01
Page 0, Reg 0x34: 0x00
Page 0, Reg 0x36: 0x01
Page 0, Reg 0x40: 0x80
Page 0, Reg 0x41: 0x7f
Page 0, Reg 0x42: 0x00
Page 0, Reg 0x43: 0x80
Page 0, Reg 0x44: 0x7f
Page 0, Reg 0x45: 0x00
Page 0, Reg 0x46: 0x80
Page 0, Reg 0x47: 0x7f
Page 0, Reg 0x48: 0x00
Page 0, Reg 0x49: 0x80
Page 0, Reg 0x4a: 0x7f
Page 0, Reg 0x4b: 0x00
Page 0, Reg 0x4c: 0x80
Page 0, Reg 0x4d: 0x7f
Page 0, Reg 0x4e: 0x00
Page 0, Reg 0x4f: 0x80
Page 0, Reg 0x50: 0x7f
Page 0, Reg 0x51: 0x00
Page 0, Reg 0x52: 0x80
Page 0, Reg 0x53: 0x7f
Page 0, Reg 0x54: 0x00
Page 0, Reg 0x55: 0x80
Page 0, Reg 0x56: 0x7f
Page 0, Reg 0x57: 0x00
Page 0, Reg 0x58: 0x00
Page 0, Reg 0x59: 0x00
Page 0, Reg 0x5a: 0x00
Page 0, Reg 0x60: 0x01
Page 0, Reg 0x61: 0x00
Page 0, Reg 0x62: 0x10
Page 0, Reg 0x70: 0x70
Page 0, Reg 0x71: 0x30
Page 0, Reg 0x72: 0x0f
Page 0, Reg 0x73: 0x04
Page 0, Reg 0x74: 0x32
Page 0, Reg 0x75: 0x00
Page 0, Reg 0x78: 0x07
Page 1, Reg 0x01: 0x00
Page 1, Reg 0x02: 0x00
Page 1, Reg 0x04: 0x00
Page 1, Reg 0x05: 0x00
Page 1, Reg 0x06: 0x00
Page 1, Reg 0x07: 0x00
Page 1, Reg 0x08: 0x00
Page 1, Reg 0x09: 0x00
Page 1, Reg 0x0a: 0x00
Page 1, Reg 0x0b: 0x00
Page 3, Reg 0x12: 0x40
Page 3, Reg 0x15: 0x01
Page 253, Reg 0x14: 0x00

For a flawed boot (minority of the time), the only difference was that register 0x14 read 0x08 and register 0x73 read 0x03. This incorrectly detected sample rate seems to match the symptom of the incorrectly set up decimation filter. Not sure if there is anything we are doing wrong? One other observation is that the PLL lock bit in register 0x28 never seems to go high. Is that a known issue or a problem with our configuration? 

Any suggestions?

Thanks!

Tim Burnett

  • More information and another question:

    I found https://e2e.ti.com/support/audio-group/audio/f/audio-forum/601776/pcm1865-pcm1865-pll-locking-problems which describes a method of determining PLL by presetting the bit to 1 then reading it back. Is this still the recommended procedure? 

    I also found that checking for lock before assigning functional blocks to the PLL output (but after enabling the PLL) does not result in the PLL even indicating lock. I could only verify lock status by enabling the PLL, assigning functional blocks to the output, and then checking for lock. Does this make sense? Normally I would check for lock on a PLL before using the output. See the following init sequence:

    Time Address Data
    -453.4us 4BW 00 FE reset
    -376.2us 4BW 00 00 page=0
    -299.3us 4BW 70 71 pwr=standby
    -222.2us 4BW 0B 00 fmt=i2s
    -145.2us 4BW 0C 00 tdm=2ch
    -68.20us 4BW 20 10 clk=mstr, src=sck
    8.883us 4BW 21 01 dsp1_clk=38.4M/2
    85.89us 4BW 22 03 dsp2_clk=38.4M/4
    163.0us 4BW 23 0F adc_clk=38.4M/16
    240.0us 4BW 25 03 sck_div=38.4M/4
    317.1us 4BW 26 03 bck_clk=38.4M/4
    394.0us 4BW 27 3F lr_clk=bck/64
    471.1us 4BW 28 00 disable PLL
    548.1us 4BW 29 01 PLL P=1/2
    625.2us 4BW 2A 00 PLL R=1
    702.3us 4BW 2B 05 PLL J=6
    779.4us 4BW 2C B0 PLL D = 0.12
    856.3us 4BW 2D 04 PLL D = 0.12
    933.4us 4BW 28 01 enable PLL
    1.010ms 4BW 20 3E clk=mstr, src=pll (98.304M). Dsp1_clk=pll_clk/2, dsp2_clk=pll_clk/4, adc_clk=pll_clk/16, bck=pll_clk/16
    1.087ms 4BW 70 72 pwr=sleep
    1.164ms 4BW 11 50 gpio3=dout2
    1.241ms 4BW 71 30 DSP: HPF en, IIR en
    1.318ms 4BW 06 50 mux adc1L=1diff
    1.395ms 4BW 07 50 mux adc1R=2diff
    1.473ms 4BW 08 60 mux adc2L=4diff
    1.550ms 4BW 09 60 mux adc2R=3diff
    1.627ms 4BW 01 28 adc1L gain=20dB
    1.704ms 4BW 02 28 adc1R gain=20dB
    1.781ms 4BW 03 00 adc2L gain=0dB
    1.858ms 4BW 04 00 adc2R gain=0dB
    1.935ms 4BW 00 00 page=0
    2.012ms 4BW 28 11 preset PLL lock bit
    2.090ms 4BW 28 read back PLL lock bit
    2.163ms 4BR 11 PLL locked
    2.209ms 4BW 70 70 pwr=run
  • Hi Tim,

    Can you confirm where in the sequence the SCLK is active, or is it always active prior to the device initialization? Also, is the output of your oscillator 3.3V CMOS logic? Is there anything else tied to the XI pin?

    Your clock setup looks good so I don't have any concerns there. Regarding the PLL lock bit we have had other users report issues with this but generally it can be resolved by fixing errors in the clock setup. Since that's not the case here I suspect there are certain conditions that do not trigger the PLL lock flag, but unfortunately I don't have a lot of insight as to why. My suggestion would be to follow the procedure outlined in the post you mentioned and read back that sample rate status register after configuration to verify everything has been configured properly. 

    When your system does start up improperly, is it sufficient to enable/disable the PLL or toggle the IC in and out of a standby state?

    Best,

    Zak

  • Hi Zak, thanks for the reply.

    The oscillator output is 3.3V CMOS, tied to the SCKI pin. It is active for at least 1 second prior to device initialization. The XI pin is not connected. 

    Following the 2nd sequence I posted has resulted in the system seeming to always start up properly, however I don't understand why the 1st sequence would have caused any issues. This lack of understanding has me worried that the problem will show up again in the future. 

    The system software is set up to only write the i2c registers at startup, so it's a bit difficult to selectively write the registers after the fact. 

    Regards,
    Tim

  • Hey Tim,

    I suspect that this might be an issue with your designated clock source and when you switch the device to the run state. Initially, you're setting the device in master mode with SCLK as the source and configuring all of the dividers for this SCLK. Then in the last step of your initial script you change the clock source and all of the dividers to accommodate the higher speed PLL clock. There's only 0.1ms between configuring these clocks and you telling the device to go into the run state. I don't have a value for how long it should take the output of the clock dividers to stabilize, but I think this is a kind of race condition between the output of the clock divider being stable and the device being set to run. 

    I think your second script might work better because you have a much longer delay between the clock configuration and the run command. Could you try the first script you used with a 1ms delay added after the clock config and before putting the device in 'run'?

    Best,

    Zak