• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 31 subscribers
  • Views 245 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

TLV320ADC3101: Problems with Re-Sync feature

Steffen Pilz
Prodigy 10 points
Part Number: TLV320ADC3101

Hello,

 We have a problem with re-sync functionality. Here are some more details about our settings.

We use the "left justified mode" with 16 bits. BCLK and WCLK are provided by an external µC, codec acts as a slave. BCLK source is 8 MHz and is brought to 10.24 MHz by codec PLL. By 128 oversampling we then reach the ADC_FS of 8 kHz (= WCLK).

In our case, that means that the jitter of the rising WCLK edge must be smaller than +/- 390 ns (FS/4) related to the datasheet entry. I think we can meet this condition. Is it ok, when BCLK and WCLK already running while codec initialization? In our case the 8 MHz signal (BCLK source) is running before codec is initialized. The WCLK signal (8 kHz) is running after initialization. We have noticed that approx. 380 ms of data is available via DOUT after start and then only 0 is sent. How can this behavior be explained? Normally everything should start again when the condition < FS/4 is faulty. We have set bit D1 and bit D0 in the register 34 (Page 0). If we set only bit D1 then data will be sent. However, data are not plausible. When we not use the re-sync functionality everything works fine, and data transmitted as expected.

Is it important to follow the correct order when writing the registers, (e.g.ADC power up – Reg 81) after Page 1 entries have been written (see data sheet)?

 

Best regards,

Steffen

  • 0
    TI__Mastermind 23050 points

    Hi Steffen,

    There shouldn't be any problems in initialization regardless of whether BCLK and FSYNC are running. Can you share your clock configuration for review? You typically shouldn't need to use the resynchronization feature unless you have excessive clock drift or other errors in the clock generation.

    Generally yes it is recommended to finish the ADC and PGA configurations prior to powering up to avoid any unwanted noise on the output from configuration.

    Best,

    Zak

  • 0 in reply to Zak Kaye
    Prodigy 10 points

    Hi Zak,

    In general, we still have an understanding problem with functionality. Even if the condition FS/4 is violated in the meantime, a resynchronization should take place. In our case, no data will be output.

    A few more information about our approach. We configured the codec using demo board, tested it and stored the settings of Pages 0, 1, 4 and 5 via the register tables in arrays in our C code. On our current target system, we first perform the hardware reset, then the software reset and initialize the codec by using all registers of 1 - 127 of pages 0, 1, 4 and 5. Then individual registers of pages 0 and 1 are written, in which the setting differs individually from the basic settings of the demo board. In our case, on page 0, this applies to PLL settings (register 7, 8), processing blocks (register 61), AGC control (register 94 – 98), volume control (register 84) and on Page 1 the Bias Voltage (register 51). In the appendix I sent the settings.

    It is also strange that no data is sent if the ADC is switched on (register 81) at the end of the configuration and not as currently, if all registers are serially initialized. This also contradicts the example in the data sheet.

    As mentioned, when re-sync is turned off, the data is fine. Once the feature is used, we don't get any data. Do they still have ideas now that parameterization is known?

    Best regards,

    Steffen

    uint8_t Codec_Page_0_Reg_Values[127] = {0x00,0x20,0x00,0x07,0xC1,0x05,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x81,0x8A,0x80,0x80,0x04,0x00,0x00,0x01,0x81,0xC0,0x00,0x06,0x81,0x00,0x00,0x10,0x00,0x00,0xCC,0x00,0x02,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x12,0x02,0x02,0x00,0x00,0x00,0x44,0x00,0x01,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x42,0x80,0x00,0x00,0x00,0x00,0x00,0x7F,0x00,0x00,0x00,0x00,0x00,0x00,0x3E,0x7F,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00};
uint8_t Codec_Page_1_Reg_Values[127] = {0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0xFF,0x00,0x3F,0x3F,0x00,0x7F,0x00,0x80,0x1A,0x00,0x03,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00};
uint8_t Codec_Page_4_Reg_Values[127] = {0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00};
uint8_t Codec_Page_5_Reg_Values[127] = {0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00};

--> these are the initial values and starts allways with register 1
--> written to codec in loops 


--> after that the following registers are written:

	//*********   select page 0 from CODEC register
	i2c_codec_page_select(I2C_CODEC_REG_0, I2C_CODEC_PAGE_0); 
	delay_ms(1);
	
	// Reg 7 - D Value PLL MSB
	i2c_reg			= 7;
	i2c_write_buf	= 0x04;
		
	i2c_write_data(i2c_reg, &i2c_write_buf, 1);
	delay_ms(1);
	
	// Reg 8 - D Value PLL LSB
	i2c_reg			= 8;
	i2c_write_buf	= 0xB0;
		
	i2c_write_data(i2c_reg, &i2c_write_buf, 1);
	delay_ms(1);
	
	// Reg 34 - I2S sync
	i2c_reg			= 34;
	i2c_write_buf	= 0x00; // re-sync off because it doesn´t work when switch on 
		
	i2c_write_data(i2c_reg, &i2c_write_buf, 1);
	delay_ms(1);	
	
	// Reg 61 - processing blocks 
	i2c_reg			= 61;
	i2c_write_buf	= 0x04; 
	
	i2c_write_data(i2c_reg, &i2c_write_buf, 1);
	delay_ms(1);
	
	// Reg 94 - right AGC control 1
	i2c_reg			= 94; 
	i2c_write_buf	= 0xB0; 
	
	i2c_write_data(i2c_reg, &i2c_write_buf, 1);
	delay_ms(1);
	
	// Reg 95 - right AGC control 2
	i2c_reg			= 95;
	i2c_write_buf	= 0x2D;
	
	i2c_write_data(i2c_reg, &i2c_write_buf, 1);
	delay_ms(1);
	
	// Reg 96 - AGC Max Gain
	i2c_reg			= 96;
	i2c_write_buf	= 0x3C;
	
	i2c_write_data(i2c_reg, &i2c_write_buf, 1);
	delay_ms(1);	

	// Reg 97 - Right AGC Attack Time
	i2c_reg			= 97;
	i2c_write_buf	= 0x00;
		
	i2c_write_data(i2c_reg, &i2c_write_buf, 1);
	delay_ms(1);
	
	// Reg 98 - Right AGC Decay Time
	i2c_reg			= 98;
	i2c_write_buf	= 0x00;
	
	i2c_write_data(i2c_reg, &i2c_write_buf, 1);
	delay_ms(1);	
	
	
	// Reg 84 - Right ADC Volume Control
	i2c_reg			= 84;
	i2c_write_buf	= 0x00;
	
	i2c_write_data(i2c_reg, &i2c_write_buf, 1);
	delay_ms(1);
	
	
	//*********   select page 1 from CODEC register
	i2c_codec_page_select(I2C_CODEC_REG_0, I2C_CODEC_PAGE_1); 
	delay_ms(1);	
	
	// Reg 51 - set Bias voltage to 2,5V
	i2c_reg			= 51;
	i2c_write_buf	= 0x10;
	
	i2c_write_data(i2c_reg, &i2c_write_buf, 1);
	delay_ms(1);

  • 0 in reply to Steffen Pilz
    TI__Mastermind 23050 points

    Hi Steffen,

    First, I would strongly recommend following the datasheet sequence and to not power up the ADC channels until the page 1 registers have been programmed. 

    To explain the ADC re-sync: After ADC power-up, we synchronize the internal DSP (used for decimation filter for ADC) instruction counter with WCLK (or FSYNC) phase so that internal DSP frame based processing is locked with WCLK/FSYNC phase (and this also helps to optimize group-delay as well) however if in system for some reason WCLK/FSYNC frequency sees glitches/disturbances then the locking gets disturbed and may cause mis-processing in DSP like data drop/repeat etc and cause performance issues. Therefore after power-up sync/lock we monitor the instruction counter value for every frame with respect to WCLK/FSYNC edge and if we see drift crosses more than 1/4th frame then we generate error flag to re-sync DSP again with WCLK/FSYNC.

    So in summary, if in system WCLK/FSYNC behave periodically cycle-by-cycle then re-sync situation won't occur, however if any issues in the system cause glitches or disturbances in WCLK/FSYNC then it will cause re-sync.

    If you're not getting data output with the re-sync then I think you likely have a clock configuration issue. You can't have an 8MHz BCLK and run the device at 8kHz sample rate. If you mean to say that you feed an 8MHz to the MCLK and then generate a 1.024MHz BCLK this would be acceptable, but 10.24MHz would be too large of a BCLK/WCLK ratio.

    Best,

    Zak

  • 0 in reply to Zak Kaye
    Prodigy 10 points
    Hi Zak,
    Thank you for your comments. Unfortunately, we did not succeed with the recommended settings. To test even further, we went back to the demoboard and tried to test the example with USB audio. MCLK = 11.2896 MHz, BCLK = 2.8224 MHz, WCLK = 44.1 kHz. With this setting, we see data on the oscilloscope at DOUT. If we set re-sync with our software via I2C and activate the USB audio settings, no data is sent again. Please don't misunderstand, we probably don't need this feature, but we'd like to understand it and actually use it. What we also noticed, in the GUI of the demoboard you can not activate / deactivate the re-sync. Is there a reason for this? Can you maybe give us a setting where the re-sync feature is activated (register 34 = 0x03), which we can check on the demoboard?
  • 0 in reply to Steffen Pilz
    TI__Mastermind 23050 points

    Hey Steffen,

    I'm sorry you're seeing issues with this feature. Can you clarify in your test with the demoboard are you enabling this re-sync feature with a direct I2C write and seeing proper functionality? This is an option if you wanted to add a write to this register to one of the init scripts provided. 

    Is it only when you use your own software that the data ceases?

    To be perfectly honest this isn't a feature I have any direct experience with and I'm not sure how to test this properly on our EVM since I can't apply sufficient delay to the clock lines to actually trigger a re-sync. 

    Best,

    Zak 

  • 0 in reply to Zak Kaye
    Prodigy 10 points
    Hi Zak, We set the register with the sync functionality directly over the I2C bus, not via the script of the GUI. I could try that, but not until next week. However, it will have the same effect as when the register is written by the script. If you have the demoboard TLV320ADC3101-K available, you could also test it. Even with this board, we have the problems that we don't see data at DOUT. The clock source is from the µC from the lower board and we assume that it is correct and we don´t have clock shifts. You do not have to delay the clock lines, because no data is output when register 34 is described with 0x03. Can you test that? Choose settings to output data and then describe register 34 accordingly and please tell me what happend.
    Best, Steffen
  • 0 in reply to Steffen Pilz
    TI__Mastermind 23050 points

    Hey Steffen,

    I apologize for missing to follow up on this. I wanted to let you know that I tested TLV320ADC3101EVM-K with register 34d set to 0x00, 0x02, and 0x03 and did not see any change in behavior. It did not halt the data in the way you have described so I'm not sure why this would happen unless your system has some issues with the clock integrity.

    Best,

    Zak