• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 29 subscribers
  • Views 205 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.

TLV320AIC3204: ADC & DAC gian status flags are always inactive

Dimitrios Papadopoulos
Intellectual 640 points
Part Number: TLV320AIC3204

Hello all,

We are trying to verify the proper operation of the ADCs and DACs of TLV320AIC3204, after powering up. Polling power status (P0_R36 bit 2 and bit 6 for ADCs and P0_R37 bit 3 and bit 7 for DACs) works as expected (those bits eventually change from "0" to "1"). However the gain status flags (P0_R36 bit 3 and bit 7 for ADCs and  P0_R38 bit 0 and bit 4 for DACs) always stay at "0" although codec is working as expected. Are these flags expected to work somehow or should we ommit this check?

Please note that, in SLAA473A page 6, these registers are expected to become "1" after a proper codec wake up from sleep or standby. Admittedly we don't use sleep or standby modes in our application but we would expect these flags to work in any case, since the purpose of these registers is to verify that "Gain Applied in xxx is equal to Programmed Gain in Control Register".

The programming sequence we use is the following:

  1. Hard-reset the CODEC via the CODEC Reset pin
  2. Wait for 1ms
  3. Soft reset CODEC
  4. Wait for 1ms
  5. Configure clock inputs, dividers and digital interface parameters (registers P0_R4...P0_R52)
  6. Configure processing blocks for ADC and DAC (registers P0_R60, P0_R61)
  7. Configure internal power regulator, power-up input CM voltage and reference (registers P1_R1, P1_R2, P1_R10, P1_R71, P1_R123)
  8. Define PowerTune Modes for ADC and DAC (registers P1_R3, P1_R4, P1_R61)
  9. Configure TX (AGC, ADC, MICPGA) path (registers P0_R83...R88, P0_R94...R96, P1_R52...R60)
  10. Power-up ADC
  11. Wait for P0_R36 D2, D6 bits (ADCs power status) to become active
  12. Un-mute ADC (registers P0_R81 then P0_R82)
  13. Wait for P0_R36 bits D3, D7 (ADCs gain status) to become “1”
  14. Configure RX (DAC, LOL/LOR) path (registers P1_R14, P1_R15, P1_R18, P1_R19, P1_R09, P0_R65, P0_R68)
  15. Apply waiting time determined by polling register P1_R63
  16. Power-up DAC
  17. Wait for the appropriate P0_R37 bits (DACs & line or headphone output power status) to become active
  18. Un-mute DAC (registers P0_R63, P0_R64)
  19. Wait for P0_R38 bits D0, D4 (DACs gain status) to become “1”.

Thank you in advance

  • 0
    TI__Mastermind 30030 points

    Dimitrios, 

    My apologies for the delayed response! 

    Are you using the EVM and GUI?  I do appear to have some issues with reading registers when using the EVM and GUI,  but when I use a generic I2C program,  I can read register 38 just fine and the bits do become a "1".

    best regards,

    -Steve Wilson

  • 0 in reply to Steve-Wilson
    Intellectual 640 points

    Hello Steve,

    Thank you for responding. We do not use EVM since it had problems running on Windows 10. It is our product board where our CPU writes the registers of TLV320AIC3204, using SPI @ 20MHz (apologies for not stating this before). SPI clock is at maximum and we plan to decrease it by a considerable amount but is this enough to explain our problems?

    In general, we do have some issues with programming this complex codec via SPI. It works in general, but some of its registers seem to require an unknown guard interval before issuing the next command. We have used guides slaa557 and slaa404c and the whole device support literature but so far we didn't notice any reference to guard intervals and flags that should be monitored for verifying a succesful programming.

    Best regards,

    Dimitrios

  • 0 in reply to Dimitrios Papadopoulos
    TI__Mastermind 30030 points

    Dimitrios, 

    There is a sequential transfer delay mentioned in the datasheet.  is that what you may be referring to?

    best regards,

    -Steve Wilson

  • 0 in reply to Steve-Wilson
    Intellectual 640 points

    Hello Steve,

    Sorry for the late reply. I am not sure the issue is related to the sequential transfer delay since the latter is smaller (20ns) than the SPI clock half-period. Therefore I assume that hte requirement is fullfilled as long as the SPI clock has 50% duty cycle (I guess it does since the SPI port we use is a dedicated one on the OMAP cpu).

    I can only suspect that various commands need different processing times inside the codec, so there must be a longer (microseconds range?) delay requirement between subsequent commands sent from the host cpu via SPI. At first, we will try to slow down the SPI clock and use a fixed delay after each command.

  • 0 in reply to Dimitrios Papadopoulos
    Intellectual 640 points

    Update:

    No improvement after lowering SPI speed to 4 MHZ and adding a 30 SPI periods delay between successive commands. Flags P0_R36 bits D3, D7 and P0_R38 bits D0, D4 are always "1". Even more interesting, the issue is still here when we execute the application line-by line, via JTAG, using the OMAP debugging environment.

    Best regards,

    Dimitrios