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.

TLV320AIC24K - ADC/DAC overflow? Programmin/standard mode?

Hi all,

1) could someone let me know more details on the ADOVF / DAOVF flags in Register 1 (D7/D4)? The note on the "overflow flags" on page 24 doesn't really say why these bits are set - I assume it is because of exceeding input volatage?  If not, then what does it mean when FIR/IIR "input range" is exceeded?

If they are not read, what happens to the data? Are they still valid? Is it just indicator or must me cleared? What happens if the user "dosn't care" about those bits?

2) Can this device work in programming mode only or it must switch to standard operation at some point of time?

best regards

OskarM.

  • Oskar,

    1) could someone let me know more details on the ADOVF / DAOVF flags in Register 1 (D7/D4)? The note on the "overflow flags" on page 24 doesn't really say why these bits are set - I assume it is because of exceeding input volatage?  If not, then what does it mean when FIR/IIR "input range" is exceeded?

    If they are not read, what happens to the data? Are they still valid? Is it just indicator or must me cleared? What happens if the user "dosn't care" about those bits?

    - The ADOVF / DAOVF are status bits which indicate an overflow in the FIR/IIR decimation and interpolation filters have occured, which is typically trigerred when the input signal exceeds the full-scale voltage. If these flags are used by the code inside the host processor, then, after a software reset, these flags should be cleared (by reading the register) so they can be available when an overflow event occurs. It is definitely not a step required from a functionality standpoint.

    2) Can this device work in programming mode only or it must switch to standard operation at some point of time?

    - Most customers control this part via I2C and not the programming mode on the audio bus. If programming mode is not used, then it is recommended to switch to non-programming to prevent data from the audio stream to inadvertedly change the control register configuration. In fact, it is best if the DIN pin is held low until the continuous data transfer mode has been selected via i2c to avoid such case.

    Regards,

    J-

  • Folks,

    please have a look as more question arises:

    1) Any questions regarding overflow bits appear because I do not read DAOVF/ADOVF bits. I don’t have possibility to read them at all – my software interface is able to send data without handshaking only in programming mode. Therefore I don’t have experience when these flags are set.

     The concept of ADOVF work is clear and obvious for me. Anyway please correct me if I am wrong.

    1)       If user exceeds input range of voltage for given PGA amplification - A/D converter informs about overflow so gathered data might not be useful. Is that correct?

    2)       (If user does not use FIR or IIR decimation filter) AND (the host cpu reads the register after a software reset) –> ADOVF remains 0 all the time. Is that correct?

     

    Regarding DAOVF:

    Let me pose a few questions regarding DAOVF bit which functionality is not obvious for me. Answers for these questions would be appreciated.

    I assume that I read the register after software reset so we have had nominal, error-free state.

    1)       Does codec have full dynamic of 16 bits of input word when FIR/IIR interpolation filter is on?

    2)       Does any event can trigger setting DAOVF to 1 when FIR/IIR filters are disabled (bypassed)?

    3)       Does SINC filter can trigger setting DAOVF to 1?

    4)       Does FIR filter can trigger setting DAOVF to 1? If so: does it mean that FIR introduces gain greater than 1 in passband? Does it mean less dynamic than 16 bits of input word?

    5)       If IIR interpolation filter triggers setting DAOVF to 1 it means that I cannot feed codec with full scale samples in range [-32768, 32767]. Is that right? So I do not have full range in this case as well.

     2)

    Considering your answer regarding programming mode: If I am able to assure that data/control stream is valid in programming mode there is no point in switching to another mode?

    best regards

    OskarM.