TLV320AIC31: 6PAIC3109TRHBRQ1 LOP LOM

Hi,

Is the inrush current found when the audio file is started or when the system is powered up? How is the file being provided to the codec, and what is the sequencing in terms of power up, clocks provided, when the file is given, mute states, etc?

Thank you,
Jeff McPherson

Hi Jeff

We found the inrush current only happens before audio file transmitted with I2S (ignore the abnormal waveform of clock signal, it's probe issue), not during power up. Power up sequence is done much ealier than audio file transmission.

Writing register is a process before audio file transmission every time.We found the inrush current happens after register writing with I2C, is it possible that the inrush current happens during configuration?

We captured the I2C bus, could you help to check if there is anything wrong with the written register and bits？

And what you mean about mute state? Should we set any mute state before audio file is played？

Thanks

Hi,

Why do you remove the coupling caps to the amp? You see the LO output jumps to about 1.35V which is the default output common voltage setting.

You need to place the coupling caps as the amp needs AC-coupled input and we also recommend placing a LPF (R=100 and C= 47nF) before the AMP input.

No, you don't need to set to mute before playing the file.

Regards.

hi:

I removed coupling capacitors just for checking which side ( the amp or codec) causes the abnormal waveform. It seems codec generated the abnormal waveform before playing audio file, and the waveform is transmitted to AMP, which caused inrush current. We already measured this abnormal waveform with the application of coupling capacitors before removing them to locate the source.

Hi Lelian,

As Peter also mentioned there should be a low pass filter as well as the AC coupling caps to the amp input. I see a resistor divider but no filter.

Do you see this happen with any audio file or only a specific one?

Thanks,
Jeff McPherson

hi Jeff:

As you can see, the it's basically a pulse represented in the signal, I don't think a LPF can solve the problem, We can optimize the design in our next product.

It happens with any audio file, not just a specific one.

Is it possible that some kind of I2C configuration causes this pulse?

I also captured some other abnormal pulses generated by codec with green color, which only happens when there is I2C register writing with yellow color. 

There was no audio file played in this circumstance, just I2C configuration during startup. 

Hi Lelian,

Pulses are high frequency in nature, a low pass filter could help attenuate them. 

From your follow up post this looks like cross talk. Can you try disconnecting the output from the codec to the amp by removing the 0ohm resistors and seeing if the pulse behavior changes? Both for I2C activity and when playing audio.

Best regards,
Jeff McPherson

Hi Jeff:

About the LPF, as the first and second waveforms I attached at the beginning, it's the differential voltage between LOM and LOP causes inrush current, AS long as there is a differential voltage larger then normal value, there would be inrush current. A LPF can slow down the ramp up and ramp down of pulses, but it cannot eliminate the differential voltage between LOP and LOM.

About the further tests. I will attach couple of waveforms at the same moment with and without resistors for better comparison. LOM signal is in blue color, SDA in green color.

1. The following waveform is with 0 ohm resistors at startup phase:

2. The following waveform is without 0 ohm resistors at startup phase

zoom in the pulse:

3. The following waveform is with 0 ohm resistors while playing audio file:

zoom in LOM waveform before playing audio file:

4. The following waveform is without 0 ohm resistors while playing audio file:

zoom in  LOM waveform before playing audio file:

I also noticed that only the pulse before audio file causes AMP supply voltage drop (in green color as following), the other pulse have no affect. So the main issue is to eliminate the pulse before playing audio file.

Could you explain why there is crosstalk? and do we need to do something about that?

Hi Leilan,

From the scopes it looks like I2C pulses are not coupling onto the output during playback so you probably don't need to worry about it.

Have you tried adjusting the Driver Ramp-up Step Timing Control in Register 42 (0x2A)? Lengthening the step up time may help prevent the pulses.

Best regards,
Jeff McPherson

hi Jeff

I set register 42 to 0x4c which is 01001100 (0100: Driver power-on time = 10 ms, 11: Driver ramp-up step time = 4 ms, 0: Weakly driven output common-mode voltage is generated from resistor divider off the AVDD supply), the inrush current still exist and causing voltage drop, since there is still abnormal differential voltage transmitted to AMP

Is there any other registers related to ramp up?

He Lelian,

Those are the only registers.

Can you elaborate more on the sequencing between initialization and playback? It looks like from this picture and some of your previous ones that I2C transactions are occurring immediately before playback. For example the abnormal Line Out behavior seems to occur almost immediately after LOP and LOM rise to their common mode levels. Is is possible to add delay between when the I2C writes occur and when the playback actually begins? It may be related to your earlier observation of the voltage supply sagging before playback.

Thanks,
Jeff McPherson 

Hi Jeff:

The abnormal Ecall out waveform occurs because of inrush current caused by differential voltage between LOM and LOP. Inrush current follows differential voltage of LOM and LOM, ECALL OUT followes inrush current, voltage supply drop follows inrush current. The thing is why LOP and LOM show a differential voltage after reaching common mode level(1.35V). And as you can see, the differential voltage disappears after around 10ms, LOP and LOM voltage level return to normal level. 

If it's I2C transaction related, how it happens.

This is what we wrote into CODEC before playing video, and for some reason, we are not able to change these I2C configurations, even the timing.

The I2C message before LOP and LOM pulse is writing 0x09 to register 56, register 56 is LEFT_LOP/M Output Level Control Register

Hi Leilan,

I think the problem is that the driver is being powered up and unmuted at the same time. The best practice is to power up the driver while remaining muted and then release the mute state. Otherwise the driver is vulnerable to these "pops" and unexpected effects.

Best regards,
Jeff McPherson 

hi Jeff:

Could you explain how we should set the registers in detail? Which register for setting mute state, and which register for power up process.

Hi Lelian,

Sure. Register 0x56 should first be written as 0x01 to power up the driver. Then wait a short delay (a few milliseconds is all) before unmuting the driver by setting 0x56 to 0x09.

Best regards,
Jeff McPherson

Hi Jeff:

I noticed the 0 bit of 0x56 register is READ only type. My concern is that writting 1 to this bit doesn't really power up driver.

Hi Lelian,

I noticed the same, but I compared it against our EVM GUI, and it does in fact power up the driver. It's a typo in the register map.

Best regards,
Jeff McPherson