• Answer Suggested

TS3A225E: TS3A225E losing configuration

Part Number: TS3A225E

Hi,

 We have implemented in our design the two following components (see schematic in attachment)

-          TLV320AIC3100

-          TS3A225E

We are confused to observe we are losing the register settings of the TS3A225E.

Writing and reading immediately the values back is ok but after 100ms most of the time the values are lost.

PS: the TLV320AIC3100 on the same I2C bus is working correctly

Could you advise?

tx

audio.pdf

  • MBa,

    The TS3A225E has both a manual I2C control mode to configure the switch matrix and an automatic mode.   The default mode of the switch is to be used with automatic detection.

    Are you wishing to use the device in automatic detection mode or manual mode?

    What settings are you wishing to write to the TS3A225E and what is the result when you lose those settings.

    Thank you,

    Adam

  • In reply to Adam Torma:

    Adam,

    We write the I2C_INT bit of the CTRL3 register in order to get irq's whenever there are I2C register changes. (so we can detect head phones as well as microphones). What we observe is that after 'some time' the I2C_INT bit disappears (The CTRL3 register becomes zero again).

    As an experiment, we added a polling routine that dumps all registers. This is how we observed the I2C_INT bit disappears. It is not consisten when the bit goes away.

    As a result, after the I2C_INT bit drops to 0 we only get irq's if we plug in a real microphone (as we are using the chip's automatic mic detect feature), we get no irq when we plug in a headphone.

    So as a second experiment we rewrite the I2C_INT bit right before each register dump. This way we also get irq's when we plug in a head phone.

    Regards,

    Peter.
  • Peter,

    CTRL3 register /MIC_PRESENT bit defaults to 0 if you would read the register and the MIC_PRESENT pin will only pull low when a MIC is detected. You also have the option to write to CTRL3 register /MIC_PRESENT bit to 1 which will cause the MIC_PRESENT pin to pull low.

    I would not expect the CTRL3 register to change overtime unless there was an interrupt to the supply pin and the value 1 could revert back to the default 0.

    I will need to check with the design team to see if this MIC_PRESENT pin will actually behave like an I2C_IRQ and pull low for any I2C change or if it will only pull low when a mic is detected

    Adam
  • In reply to Adam Torma:

    Hi Adam
    Any feedback for us about this issue ?
    Thanks
  • In reply to MBa:

    MBa,

    I met the same issue like you.

    It seems an issue of TS3A225E(not confirmed by TI yet).
    The IC resets all writable registers after remove headphone.

    Workaround:
    Reconfigure all writable registers after MIC_PRESENT becomes high.
    Actually, it's enough to rewrite CTRL3 with 0x04.

    Hope it's helpful to you.

    Sincerely
    Forrest

  • In reply to Forrest Zhang:

    Peter,

    I'm sorry that I gave incorrect information on the ability for the MIC_PRESENT pin having the feature to being an interrupt. I have deleted the erroneous posts to help make this thread clear.

    I talked with one of the IC definers and they think that reading the INT register will automatically release the MIC_PRESENT pin, but it doesn't explain why CTRL3 register 0x41 resets the values.

    I have board set up in my lab now and will try this test to see if I can see your issue.

    1) Power up the device without anything connected
    2) Write CTRL3 0x41 register to configure MIC_PRESENT pin as an interrupt 0x04
    3) repeatedly read all registers to see if CTRL3 0x41 register settings change

    Will this test mimic what your are doing?

    Thank you,
    Adam
  • In reply to Adam Torma:

    Hi Adam,

    There are my test steps, it's very easy to reproduce:

    1) Power up the device without anything connected.

    2) Write CTRL3 0x04 register with the value 0x04 (as an interrupt)

    3) Connect the headphone. MIC_PRESENT pin becomes low (active).

    4) Read CTRL3, it's still 0x04.

    5) Disconnect the headphone. MIC_PRESENT pin becomes high

    6) Read CTRL3, it will be 0x00. Actually all registers will be reset values, it seems the IC performs an internal reset.

    PS: I notice the datesheet gives two different addresses for CTRL3.

    In the section"REGISTER MAP", the address of CTRL3 is 0x04;

    In the next section "REGISTER DESCRIPTION", it becomes "0x041".

    I believe that the address of CTRL3 should be 0x04.

    Sincerely

    Forrest

  • In reply to Forrest Zhang:

    @Adam: Yes let us start from that simple experiment.

    According to Forrest, an headphone insertion is needed for the config to be lost. I observe different behavior: periodically reading CTRL3 also causes the config to be lost and as a consequence, after that, we don't get irq's at all.

  • In reply to Peter Van Hoyweghen:

    All,

    I was able to see what you are seeing using this procedure. I eliminated one more variable and didn't use a headphone. I simply pulled up the DET_TRIGGER pin to initiate the detection sequence.

    1) Power up the device without anything connected.

    2) Write CTRL3 0x04 register with the value 0x04 (as an interrupt)

    3) Pull up DET_TRIGGER pin to initiate detection. Yes MIC_PRESENT pin becomes low (active).

    4) Read CTRL3, it's still 0x04.

    5) Remove pull up voltage from DET_TRIGGER. MIC_PRESENT pin becomes high

    6) Read CTRL3, it will be 0x00. Actually all registers will be reset values, it seems the IC performs an internal reset.

    I also tried same procedure but instead initiating the detection sequence with ctl3 register and didn't see the issue.

    Peter,

    I tried repeated reading ctl3 but it always held its value. I think something else needs to happen other than reading ctl3 to initiate the detection.

    PS: yes I saw the ctl3 0x041 address typo. It should be 0x04.

    I will think about this experiment and why the IC is resetting if the DET_TRIGGER voltage is removed.

    Thank you,
    Adam
  • In reply to Adam Torma:

    Adam & Peter,

    According to the different situations between us, I study it more detailed.

    The issue is almost identified now, it's still around the DET_TRIGGER voltage is removed.

    Once the MIC_PRESENT pin becomes high, read or write TS3A225E registers immediately, it has no response.
    It causes the host microprocessor STM32F407 sets the I2C BUSY flag.

    Previously the host program continues to read the TS3A225E registers without reset the BUSY flag,
    therefore, I report all registers have been reset to zero. (losing the configuration)

    If insert a delay about 1 millisecond after the MIC_PRESENT pin becomes high, then it's OK to read or write.

    Why is the delay required? Is there any more graceful solution?

    PS: If set CTRL3 = 0x04, the MIC_PRESENT pin is almost the invertor of DET_TRIGGER. Is that true?

    Sincerely
    Forrest