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.

TS3A225E: TS3A225E losing configuration

Part Number: TS3A225E
Other Parts Discussed in Thread: TLV320AIC3100,

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

  • 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
  • Hi Adam
    Any feedback for us about this issue ?
    Thanks
  • 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

  • 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
  • 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

  • @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.

  • 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
  • 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

  • The Summary of TS3A225E issues
    ============================
    Issue 1:
    Once remove a headset from the audio jack, read or write any TS3A225E register immediately, it has no response.

    If insert a delay about 1 millisecond, then read/write successfully.

    Issue 2:
    After remove a headset from the audio jack, TS3A225E lost its configuration.
    The host program have to rewrite the configuration again.

    Issue 3:
    Remove any headset from audio jack, and set CTRL3 = 0x01 (DET_TRIGGER),
    the register INT (address = 0x06) is equal to 0x01,
    It indicates "A standard TSR headset detected".

    How to reproduce issue 2
    =====================
    1) power up the device with the default setting.
    2) insert a 4-pole headset with microphone, the MIC_PRESENT pin becomes low.
    3) remove the headset, the MIC_PRESENT pin becomes high.
    4) you will get the voltage changes, if repeat above two steps.
    5) use a standard TSR headset (3-pole without MIC), do the same test, the voltage of the MIC_PRESENT pin keeps high.
    6) write 0x04 to CTRL3, configure the pin as interrupt.
    7) insert the standard TSR headset, the pin becomes low now. (as an interrupt)
    8) remove the headset, it back to the high voltage.
    9) insert the standard TSR headset again, the voltage never changes again.
    10) double check the value of CTRL3, it's 0x00 now.

    Sincerely
    Forrest
  • Forrest,

    Issue 1: I know that if the TS3A225E device runs a detection sequence it will take a couple of milliseconds but I'm not sure why removing a headset might initiate a detection sequence. Are you able to monitor the voltage on the DET_TRIGGER pin voltage during this case? Maybe there is an additional detection sequence initiated when you remove the audio jack.

    Issue 2: I have been able to duplicate this on my bench but haven't determined the root cause yet.

    Issue 3: This is expected. If you do not have anything inserted into the audio jack and run the detection algorithm, it will detect as a 3-pole device. The device will see that the impedance between tip and ring2/sleeve a equal since both of them will be high impedance or open circuit.

    Thank you,
    Adam
  • As we continue to work through this issue would you let us know if the work around proposed above is able to be implemented in your system?

    Thank you,
    Adam
  • Adam,

    After apply some software WORKAROUND patches, the chip works fine.
    Therefore, I don't plan to any more test on it.

    Issue 1: Insert a delay after interrupt trigger, then it's succuessfully to query IC.

    Issue 2: Although the reason is unknown, just rewrite the configuration after headset removed, then it works.

    Issue 3: Just be confused by the headset present definition.

    Sincerely
    Forrest