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 fails to detect a MIC(/MIC_PRESENT dis-asserted and only headphone is detected) when the board is being powered on after a headset is attached first.

Part Number: TS3A225E

Hi Sirs,

TS3A225E can always successfully detect both the MIC and headphone right after a headset is being attached during the OS(windows) operating but fails to detect a MIC(/MIC_PRESENT dis-asserted and only headphone is detected) when the board is being powered on after a headset is attached first.

Please help provide a guidanace on the issue.

Thanks,

Eric Fu

  • Eric,

    Without more information about your system, my best guess would be that there may be an internal mechanical switch on the audio jack itself that switches states once it's inserted into the jack. So when this is plugged in, the mechanical switch in the audio jack has already changed state and there will be no voltage transition seen to initiate the detection sequence since the TS3A225E needs power detect this.

    If you could send more information on your system setup though we can run through it and see if there's any other potential areas where this problem could be occurring. 

    Thanks!
    Rami Mooti

  • Hi Rami, 

    Below are the circuits. 

    The 'det_trigger' rising can be found when the board is powered on but no 'mic_present' assertion is observed. 

    I guess the mic detection may have problem during the time when the board is being powered on. There is a statement in the datasheet that shows the earlier signal or noise on tip or ring could cause the detection to fail. Could you please explain more detail about that? And provide me a debug guidance. Thank you, 

  • Eric, 

    With regards to your question where you asked about 'earlier signal or noise on tip... causing detection to fail'. I'm assuming you mean this tid bit in the datasheet?



    Here the recommended audio jack (Figure 21) is highlighted as it doesn't have the problems as the poor audio jack in figure 20. If you see in Figure 20, there can be a case in which Ring1(pin2) and Ring2(pin3) are connected and the DET_TRIGGER (pin6) is asserted but the tip of the audio jack hasn't actually reached TIP(pin1). This would lead to a faulty detection, or an early-triggering, since the device would think that the audio jack is connected when in reality it isn't fully inserted.
    In figure 21, the recommended audio jack, The only way for the jack to be detected is if the tip reaches pin1.



    With regards to the issue at hand, we'll take a look at this and get back soon with regards to any design problems that may be giving you the issue. 
    In the meantime, here are some debugging issues that you may look into:

    • Experiment by plugging in and unplugging multiple headsets and see if the same issue occurs?
    • How fast are you plugging in the headset? Plugging in the headset too slow can result in incorrect detection. Choosing the proper jack (as above) is a solution to this.
    • If there is a mic detected the MIC_PRESENT pin will pull low.  Can you probe that node? Are you seeing the expected high to low waveform?
    • Could this be a software problem? Could you increase the debounce time? Or software trigger (I2C) a detection sequence?
    • You could measure resistance during the two different cases you've mentioned as well in an attempt to see if there are any functional differences between plugging in the mic while the device is on or off.

    Let me know if anything here helps or gives you some insight on the problem. I'm hopeful that it will but in the meantime we will also take a closer look at your design and i'll let keep you informed if any solution is found!

    Thanks,
    Rami Mooti

  • Hi Rami,

    I attached two measurements below.

    The first one is when TS3A225 fails to detect a MIC. The 2nd one is when TS3A225 successfully detects a MIC. The issue only happens when the board is powered-on from off after the headset is attached. 

    No problem when hot-plugging in Windows.

    Thanks,

    Eric Fu

  • Eric,

    This is interesting and from examining your schematic there isn't anything that immediately jumps out at me that would be the problem. 
    Another method I would try to debug this issue, if at all possible, is trying to safely manually pull that DET_TRIGGER pin low then reassert it high while the MIC_PRESENT is still connected the entire time. For clarity, here's what I mean:
    1. Turn off device
    2. Plug in mic
    3. Power on device
    (At this point we should see a fail case that you're seeing where the DET_TRIGGER is high and MIC_PRESENT is high indicating no mic present)
    4. With a jumper or wire of some sort, run the DET_TRIGGER to ground. The mic is still plugged in at this point. 
    5. Release the wire you use to ground and let it run high. It should run high without the need to connect to a 3.3V line but you may have to if it doesn't. 

    We're looking to see here if the mic is detected after the second detection, following the manual assertion to the low state. It's important for the mic to remain plugged in the entire time though. If the mic is detected, the device itself may take a second to ramp up before it can actually be functional so the DET_TRIGGER is reaching the high state too quickly, relative to the start up time.
    Let me know if this is feasible for you to check and what the results are!

    Thanks,
    Rami Mooti

  • Hi Rami,

    Please find the below measurement. I think you might be right. DET_TIGGER rising should be delayed but do you know the exact amount of the delay time?

    And it's still strange to me that the rising needs to take longer to detect a MIC when the board is powered on from G3(AC off) to S5(AC on) and then S0(power button pressed), but shorter when the board is powered on from S5 to S0. The TS3A225E should be off in either G3 or S5.

    Thanks,

    Eric Fu

  • Eric,

    I agree that it's a bit strange but I would guess it would have to do with a transient voltage spike from turn on. Do you have constraints on how quickly you need this detected? I foresee a solution, explained below, but the detection wouldn't be initiated until after 3 or 4 seconds after start up, which I hope is sufficient.

    The detection sequence duration can be up to 500ms. However, that's just internally in the device. When you add the external R1 and C1 this adds time as well as you'll be charging that cap too. The R1 and C1 combination will allow for this delay to be toggled. It looks like the triggering occurs right around 2V. It looks like it triggered properly at around the 4second mark from your previous scope shot so we're not far off. Could you try and increase the C1 value (I believe you have a 10uF at C417 there now) or R1 (R449, don't see a value) so it'll reach that value a bit later?
    Let me know if this works.  

      

    Thanks,
    Rami Mooti

  • Eric,

    While i'm hopefully the above help, another thought I'm having with regards to the change in startup time is where the power is coming from. Is the supply for the device and the system all the same or is there an independent supply for the TS3A225E? There may be something in powering sequence of your system as a whole that changes when powering up the device by itself vs powering up everything. But I may be grasping at straw with this but definitely worth looking at 

    Thanks,
    Rami

  • Hi Rami,

    I'd ever changed the power sequence by having the TS3A225 connect with a standby 3.3V(on at S5~S0) and Jack detection pull-up connect with an S0 3.3V. But, it didn't work.

    About increasing the RC to delay or slow the rising of the "DET_TRIGGER", it worked with my on-hand boards, but it didn't with our production-line boards.

    I'm not sure if the RC values as those in the below green rectangle area of the circuits were still small or another factor like the power noise in our production lines affected the result.

    I will ask our factory to try a bigger RC value to see if any change to the result.

    Thanks,

    Eric Fu

  • Eric,

    Sorry, it appears a previous image I attempted to attach didn't go through. Good to see it work on the on-hands board but attempt changing R1 and C1 values directly on the production-line board and see if it helps. If my previous image would have gone through I could have made this more clear earlier. Unless i've misinterpreted your schematic, the below highlights (in green) the C1 capacitor and R1 resistor that you can tweak high and hopefully see results. You've added more capacitors on the Jack Plug line and I see how that still resolves the problem.

    Keep me in the loop on how their success goes with the higher RC values and if changing these R1, C1 values helps the problem! I'm sure we're close to fixing this!

    Rami Mooti

  • Hi Rami,

    I need some time to arrange this test with more boards on my side and our factory.

    I will reply to you in a couple of days.

    Thanks,

    Eric Fu

  • Once the "AUDIO_RST_N" delays to rise, the "SLEEVE" will keep low and the MIC detection will be affected.

    After we remove R437, the issue can be solved.

    Thanks,

    Eric Fu