TLV320AIC3111EVM-K: Usage of TLV320AIC3111EVM-K dev kit to debug headset issue on Android

Hello,

Is there a way to delete the schematic page that I attached?  My management is not happy that I posted it.

Thanks.

--ken

Hi Ken,

The Controller board is always the master and was programmed with standard I2S format.

What that means is BCLK is not inverted, so you should set line 74 (address 0x1d, bit D3=0) to BCLK is not inverted.

R19+C23 or R20/C24 are LPF network.

Here is an apps. note on headset detection.

https://www.ti.com/lit/an/slaa454/slaa454.pdf?ts=1682031087010&ref_url=https%253A%252F%252Fwww.ti.com%252Fproduct%252FTLV320AIC3109-Q1%253FkeyMatch%253DTLV320AIC3109-Q1%2526tisearch%253Dsearch-everything%2526usecase%253DGPN

Regards.

pdjuandi,

Thanks for the quick response.

A few questions:

So, I assume then that I should also set the BCLK and WCLK to input as well (register 27, bits 2 and 3)?

Are the low-pass filters on the headphone outputs recommended?  This is to reduce / eliminate quantization noise from the DAC?  Maybe not as important at 48 KHz sampling vs 8 KHz?

Thanks for the app note on headset detection, but I think my headphone / headset detection is working well.  However, I would like more information regarding optimum recovery of the audio signal from the headset microphone.  For instance, there are many different headsets available (e.g. the ones distributed with iPhones, Android phones, etc. and the ones that can be found at most computer stores).  The codec provides several different parameter settings for the microphone input, such as input impedance matching, gain settings, etc.  The problem I am facing is that this product will need to support all, most, or at least many of the headsets available in the market.  What is the best way to do this; do I need to develop some kind of adapting headset interface, or is there a single set of parameters that can be used to cover a wide array of headset microphones?

Also, is there a miniDSP filter or algorithm recommended that can help with this?

Any suggestions you can provide here are welcome.

BTW, base on the answer you provide on the BCLK and WCLK signal configuration question above I will let you know if this resolved my problem or not.

Thanks.

--ken

Great, thanks.

--ken

Hi Ken,

-. Yes if you are using the EVM controller as master then the device needs to be in slave mode or input. 

-. In your case it's not necessary to place the LPF since it's not connected to external amplifier.

-. This codec device does not differentiate either CTIA or OMTP headset type, you have to handle that externally. 

-. The 2 headset types are basically a TRRS with MIC and GND swapped on the last RS so no filter/algorithm for that. I believe you can find IC that handle this like https://www.ti.com/lit/ds/symlink/ts3a227e.pdf?ts=1682118486987&ref_url=https%253A%252F%252Fwww.ti.com%252Fproduct%252FTS3A227E

Regards.

pdjuandi,

I was able to execute my scripts on the EVM and most of the registers resulted in the same values as on my target.  The registers that did not match up were mostly due to reserved bits or flag bits that were different, or the bit fields that I had to change because of the differences between my target hardware and the EVM hardware (e.g. my target is master, driving WCLK and BCLK, while the EVM is master; also the target is using MIC1RP as microphone input while the EVM is using MIC1LP).

After configuration using the two scripts, the EVM can recover the audio signal from the microphone and put it on the I2S bus.  However, using nearly the same configuration, the target is not able to do this, at least the I2S signals look very different.  So I am in debug mode, and here I am running into some issues.

One difference on the I2S bus is that the target is using a 16-bit wide I2S frame (16-bits per channel), while the EVM is using 32-bits per channel.  Of course, another significant difference is the clock mastering differences between the EVM and target.  (Just to clarify, it is not possible to run the EVM with MCLK and WCLK driven by the codec, correct?)

Based on my original problems getting the USB connected, I had the EVM configured for 44.1 KHz sampling rate because I followed the trouble-shooting guide you referenced step-by-step.  Today I was able to reconfigure the EVM to 48 KHz sampling rate, which is what the target is running at.

After I made this change, I found that my scripts no longer will configure the EVM properly.  Looking into this in some detail, I found that one reason for this is that when the software reset command is executed on the codec (set register 0:1 bit 0 to '1'), the registers are not put in the default reset state according to the data sheet.

For example, see the below screenshot.  I ran a simple script that only executes a software reset.

As you can see, more than one register is not set to its default reset value according to the TLV320AIC3111 data sheet:

Register       Data sheet reset value      Actual value after reset

      5                         0x11                                0x44

      6                         0x04                                0x1e

      7                         0x00                                0x02

      8                         0x00                                0x4c

     11                        0x01                                0x00

I am confused as to what is going on here.  Can you help me understand?

BTW, another question: is there a way to single-step through a script, or is the only way to do this to copy a line from the script, paste it into the field left of the execute button, and then click on the button?

Thanks.

--ken

You can configure the EVM to disable the I2S from the USB-MODEVM controller by setting SW2 position 4 to OFF in the USB-MODEVM, refer to page 29 of the user guide for the USB-MODEVM schematic. The codec MCLK needs to be provided by external so you can either use the MCLK from the USB-MODEVM by keeping SW2 position 5 to ON or from outside source by setting it to OFF.

Now you can configure the codec device to be master/slave mode without the I2S from USB-MODEVM.

You need to hit the refresh button in the register inspector to update.

There's no stepping through other than running it one at a time or put it in the field next to the execute button and run it separately.

Regards.

pdjuandi,

Ok, I will try that.  But, why is the software reset command not working when the EVM board is configured for 48 KHz rather than 44.1 KHz.  To be clear, all I did is reconfigure the firmware on the EVM to use the USB-AudioEVM304_48KHZ.bin file instead of the USB-AudioEVM304_441KHZ.bin file, and now the software reset does not reset the registers properly, and as a consequence my scripts are not working either.

--ken

One more thing I should have mentioned is that after I made the configuration change to use the USB-AudioEVM304_48KHZ.bin firmware the WCLK is operating at 48 KHz as expected, instead of 44.1 KHz.

--ken

pdjuandi,

I need some urgent help here.  I made the change you recommended: setting SW2 position 4 to OFF.  This does indeed disable the WCLK and BCLK drivers on the baseboard, allowing me to configure the TLV320AIC3111 to drive those two signals, as on my target. 

For some reason, this also helps with the software reset.  I didn't verify every register, but the ones that I listed earlier and others seem to be getting reset properly.

However, my scripts still fail.  The reason seems to be that some commands are ignored.  See the simple test case below:

All this script does is reset the codec, and then attempt to set register 0:27 to 0x0c.  But for some reason the write command is being ignored.  The subsequent read command reads back 0x00.

I can manually set the bits to 0x0c by clicking on the bits:

...and this does seem to set the bits, but the register inspector is unable to read the register back properly (using manual execute).

What is going on here?  Between the software reset problem, and this inability to set and read certain registers, it is apparent that this EVM board and/or software is unreliable or has bugs; how can I trust it to help me solve my problem?

Does your EVM board behave the same?

I thought that purchasing this board could help me solve a fairly simple problem; I've invested nearly two weeks in it so far and am seriously behind schedule.

--ken

w 30 00 01 is not for reset it's setting the page to 1.

to reset you need to write:

w 30 00 00 for page 0

w 30 01 01 to reset.

You can manually read the register in the command window like what you did, but make sure you are setting the correct page#.

pdjuandi,

You are correct, thank you.  My mistake.

My scripts are working again now.  Thanks much.

--ken

Good to know, I close this for now.

pdjuandi,

Please don't close this case yet, or can we maybe move it to another case number.  I am still struggling with this.

After all of the reconfigurations, I believe I now have the EVM board configured the same as my target.  The I2S receive waveforms look the same.

However, I am still not recovering the audio signal on either platform.

I have attached updated scripts that I am running on the EVM to configure it; first the Android_boot.txt script, then the Android_headset_detect.txt script.

i i2cstd

#     --------------------------------------------------------------- page 0 is selected 
w 30 00 00
#      0:1  -- RESET:     s/w reset
w 30 01 01
#      0:51 -- GPIO1:     GPIO1 is mapped to INT1 output
w 30 33 16
#      0:48 -- INT1CTRL:  HS detect, BUTTON detect, short circuit, engine interrupts enabled
w 30 30 cc
#      0:27 -- IFACE1:    mode is i2s, wordlength is 16, BCLK and WCLK are outputs
w 30 1b 0c
#      0:29 -- IFACE2:    BCLK is inverted
w 30 1d 08
#      0:48 -- INT1CTRL:  HS detect, BUTTON detect, short circuit, engine interrupts enabled
w 30 30 cc
#      0:51 -- GPIO1:     GPIO1 is mapped to INT1 output
w 30 33 16
#
#     Note: the following AGC configuration was added manually (not from i2c log)
#      0:83 -- ADCVOL:    ADC coarse gain: 0 dB
w 30 53 00
#      0:86 -- AGCCTL1:   AGC enabled, target level -10 dB
w 30 56 a0
#      0:87 -- AGCCTL2:   2 dB hysteresis, noise threshold -50 dB
w 30 57 54
#      0:88 -- AGCMAXGAIN: 40 dB maximum gain
w 30 58 50
#      0:89 -- AGCATTACK:  20 ms attack time
w 30 59 78
#      0:90 -- AGCDECAY:  500 ms decay time
w 30 5a b8
#      0:91 -- AGCNSDEB:  0 ms noise debounce time 
w 30 5b 00
#      0:92 -- AGCDIDEB:  2 ms signal debounce time 
w 30 5c 07
#     --------------------------------------------------------------- page 1 is selected 
w 30 00 01
#      1:31 -- HPDRIVER:  OCMV = 1.65 V
w 30 1f 14
#     --------------------------------------------------------------- page 0 is selected 
w 30 00 00
#      0:67 -- HSDETECT:  HS detect enabled, 64 ms glitch reject HS only, 8 ms glitch reject button
w 30 43 89
#     --------------------------------------------------------------- page 1 is selected 
w 30 00 01
#      1:47 -- MICPGA:    Mic PGA = 0 dB
w 30 2f 80
#      1:36 -- LANALOGHPL: ?
w 30 24 1b
#      1:37 -- RANALOGHPR: ?
w 30 25 1b
#      1:35 -- DACMIXERROUTE: DAC_R is routed to the right-channel mixer amplifier
w 30 23 40
#      1:35 -- DACMIXERROUTE: DAC_L and DAC_R routed to mixer amplifiers
w 30 23 44
#      1:36 -- LANALOGHPL: Set left analog HPL volume to mute
w 30 24 7f
#      1:37 -- RANALOGHPR: Set right analog HPR volume to mute
w 30 25 7f
#      1:38 -- LANALOGSPL: ?
w 30 26 00
#      1:39 -- RANALOGSPR: ?
w 30 27 00
#      1:42 -- SPLGAIN:   SPL driver not muted, gain set to 6 dB
w 30 2a 04
#      1:43 -- SPRGAIN:   SPR driver not muted, gain set to 6 dB
w 30 2b 04
#      1:38 -- LANALOGSPL: Set left SPL gain to 0 dB
w 30 26 80
#      1:39 -- RANALOGSPR: Set right SPR gain to 0 dB
w 30 27 80
#     -----Note: I think boot-up is complete here-----
#              Large (18 second) delay
#              Probably this next part is to set up for audible boot signal:
#     --------------------------------------------------------------- page 0 is selected 
w 30 00 00
#      0:4  -- CLKMUX:    PLL_clkin = MCLK, codec_clkin = PLL_CLK
w 30 04 03
#      0:6  -- PLLJ:      J = 8
w 30 06 08
#      0:7  -- PLLDMSB:   D = 1920 (0x780), D(13:8) = 7
w 30 07 07
#      0:8  -- PLLDLSB:   D(7:0) = 80
w 30 08 80
#      0:11 -- NDAC:      NDAC divider is set to 8
w 30 0b 08
#      0:12 -- MDAC:      MDAC divider is set to 2
w 30 0c 02
#      0:13 -- DOSR_LSB:  DAC DOSR MSB set to 0
w 30 0d 00
#      0:14 -- DOSR_MSB:  DAC DOSR LSB set to 0x80
w 30 0e 80
#      0:18 -- NADC:      NADC divider is powered up, set to 8
w 30 12 08
#      0:19 -- MADC:      MADC divider is powered up, set to 2
w 30 13 02
#      0:20 -- AOSR:      ADC AOSR set to 128
w 30 14 80
#      0:30 -- BCLKN:     Set BCLK N divider to 8
w 30 1e 08
#      0:5  -- PLLPR:     PLL Power up, P = 1, R = 1
w 30 05 91
#      0:11 -- NDAC:      Power up NDAC divider (set to 8)
w 30 0b 88
#      0:12 -- MDAC:      Power up MDAC divider (set to 2)
w 30 0c 82
#      0:18 -- NADC:      Power up NADC divider (set to 8)
w 30 12 88
#      0:19 -- MADC:      Power up MADC divider (set to 2)
w 30 13 82
#      0:30 -- BCLKN:     Power up BCLK N divider (set to 8)
w 30 1e 88
#      0:29 -- IFACE2:    BCLK is inverted
w 30 1d 08
#      0:63 -- DACSETUP:  DAC left and right channels powered, set to corresponding data
w 30 3f d4
#      0:37 -- DACFLAG1:  Wait for left and right DAC channels to power up
f 30 25 1xxx1xxx
#     --------------------------------------------------------------- page 1 is selected 
w 30 00 01
#      1:32 -- SPKAMP:    Power up left and right Class D SPL and SPR outputs
w 30 20 c6
#     --------------------------------------------------------------- page 0 is selected 
w 30 00 00
#      0:37 -- DACFLAG1:  Wait for left and right Class D outputs to power up
f 30 25 1xx11xx1
#      0:64 -- DACMUTE:   Un-mute DAC outputs
w 30 40 00
#     -----Note: there is a time-out delay here before channels are muted-----
#                         Probably audible boot signal is complete
#      0:64 -- DACMUTE:   Mute DAC outputs
w 30 40 0c
#     --------------------------------------------------------------- page 1 is selected 
w 30 00 01
#      1:32 -- SPKAMP:    Power down left and right Class D SPL and SPR outputs
w 30 20 06
#     --------------------------------------------------------------- page 0 is selected 
w 30 00 00
#      0:37 -- DACFLAG1:  Wait for left and right Class D outputs to power down
f 30 25 xxx0xxx0
#      0:63 -- DACSETUP:  DAC left and right channels powered down
w 30 3f 14
#      0:37 -- DACFLAG1:  Wait for left and right DAC channels to power down
f 30 25 0xxx0xxx
#      0:29 -- IFACE2:    Disable BCLK and WCLK active when codec powered (Note: set to 0x08 on target)
w 30 1d 08
#      0:30 -- BCLKN:     Power down BCLK N divider (leave divider set to 8)
w 30 1e 08
#      0:19 -- MADC:      Power down MADC divider (leave divider set to 2)
w 30 13 02
#      0:18 -- NADC:      Power down NADC divider (leave divider set to 8)
w 30 12 08
#      0:12 -- MDAC:      Power down MDAC divider (leave divider set to 2)
w 30 0c 02
#      0:11 -- NDAC:      Power down NDAC divider (leave divider set to 8)
w 30 0b 08
#      0:5  -- PLLPR:     Power down PLL
w 30 05 11

i i2cstd

#     --------------------------------------------------------------- page 0 is selected 
w 30 00 00
#      0:44 -- INTRDACFLAG: Wait for headset insert / remove bit to get set
f 30 2c xxx1xxxx
#      0:46 -- INTRDACFLAG2: Wait for headset insert / remove bit to get set
f 30 2e xxx1xxxx
#      0:67 -- HSDETECT:  Wait for headset with microphone detect
f 30 43 111xxxxx
#
#     Headset is detected; pause for next configuration
#
#     --------------------------------------------------------------- page 1 is selected 
w 30 00 01
#      1:36 -- LANALOGHPL: ?
w 30 24 1b
#      1:37 -- RANALOGHPR: ?
w 30 25 1b
#      1:40 -- HPLGAIN:   Unmute HPL driver
w 30 28 04
#      1:41 -- HPRGAIN:   Unmute HPR driver
w 30 29 04
#      1:36 -- LANALOGHPL: Set left analog HPL volume to -13.5 dB
w 30 24 9b
#      1:37 -- RANALOGHPR: Set right analog HPR volume to -13.5 dB
w 30 25 9b
#      1:38 -- LANALOGSPL: Set left analog SPL volume to -78.3
w 30 26 ff
#      1:39 -- RANALOGSPR: Set right analog SPL volume to -78.3
w 30 27 ff
#      1:42 -- SPLGAIN:   Mute SPL driver
w 30 2a 00
#      1:43 -- SPRGAIN:   Mute SPR driver
w 30 2b 00
#      1:38 -- LANALOGSPL: Set left analog SPL volume to mute
w 30 26 7f
#      1:39 -- RANALOGSPR: Set right analog SPL volume to mute
w 30 27 7f
#     --------------------------------------------------------------- page 0 is selected 
w 30 00 00
#      0:83 -- ADCVOL:    Set ADC coarse volume to -12 dB
w 30 53 68
#      0:82 -- ADCFGA:    Mute ADC
w 30 52 80
#
#     I believe headphone outputs are on now...
#
#      0:6  -- PLLJ:      J = 8
w 30 06 08
#      0:7  -- PLLDMSB:   D = 1920 (0x780), D(13:8) = 7
w 30 07 07
#      0:8  -- PLLDLSB:   D(7:0) = 80
w 30 08 80
#      0:13 -- DOSR_LSB:  DAC DOSR MSB set to 0
w 30 0d 00
#      0:14 -- DOSR_MSB:  DAC DOSR LSB set to 0x80
w 30 0e 80
#      0:20 -- AOSR:      ADC AOSR set to 128
w 30 14 80
#      0:5  -- PLLPR:     PLL Power up, P = 1, R = 1
w 30 05 91
#      0:11 -- NDAC:      Power up NDAC divider (set to 8)
w 30 0b 88
#      0:12 -- MDAC:      Power up MDAC divider (set to 2)
w 30 0c 82
#      0:18 -- NADC:      Power up NADC divider (set to 8)
w 30 12 88
#      0:19 -- MADC:      Power up MADC divider (set to 2)
w 30 13 82
#      0:30 -- BCLKN:     Power up BCLK N divider (set to 8)
w 30 1e 88
#      0:27 -- IFACE2:    BCLK is inverted
w 30 1d 08
#      0:63 -- DACSETUP:  DAC left and right channels powered, set to corresponding data
w 30 3f d4
#      0:37 -- DACFLAG1:  Wait for left and right DAC channels to power up
f 30 25 1xxx1xxx
#     --------------------------------------------------------------- page 1 is selected 
w 30 00 01
#      1:31 -- HPDRIVER:  Power up HPL and HPR outputs, OCMV = 1.65 V
w 30 1f d4
#     --------------------------------------------------------------- page 0 is selected 
w 30 00 00
#      0:37 -- DACFLAG1:  Wait for HPL and HPR outputs to power up
f 30 25 xx1xxx1x
#
#      0:64 -- DACMUTE:   Un-mute DAC outputs
w 30 40 00
####      0:6  -- PLLJ:      J = 8
###w 30 06 08
####      0:7  -- PLLDMSB:   D = 1920 (0x780), D(13:8) = 7
###w 30 07 07
####      0:8  -- PLLDLSB:   D(7:0) = 80
###w 30 08 80
####      0:11 -- NDAC:      NDAC divider is set to 8
###w 30 0b 08
####      0:12 -- MDAC:      MDAC divider is set to 2
###w 30 0c 02
####      0:13 -- DOSR_LSB:  DAC DOSR MSB set to 0
###w 30 0d 00
####      0:14 -- DOSR_MSB:  DAC DOSR LSB set to 0x80
###w 30 0e 80
####      0:20 -- AOSR:      ADC AOSR set to 128
###w 30 14 80
#     --------------------------------------------------------------- page 1 is selected 
w 30 00 01
#      1:47 -- MICPGA:    Mic PGA = 0 dB
w 30 2f 00
#      1:46 -- MICBIAS:   Mic Bias = 2.5 V
w 30 2e 02
#
#     Note: target board uses MIC1RP instead of MIC1LP here
#      1:48 -- MICPGAPI:  MIC1LP P-term = 10k
w 30 30 40
#      1:49 -- MICPGAMI:  CM M-term = 10k
w 30 31 40
#     --------------------------------------------------------------- page 0 is selected 
w 30 00 00
#      0:81 -- ADCSETUP:  Power up ADC
w 30 51 80
#
#     Note: on target board ADC overflow flag is set here
#
#      0:36 -- ADCFLAG:   Wait for ADC power up and gain applied flags
f 30 25 11xxxxxx
#      0:82 -- ADCFGA:    Unmute ADC, fine gain = -0.4 dB
w 30 52 00

After running these scripts, this is what the I2S receive bus looks like on my scope:

...And on my logic analyzer:

To me the signals look to be in the correct format (16 bits, two's complement, MSB first, standard I2S shift, i.e. 1 bit right of frame signal), and the scope and logic analyzer corroborate each other.

At the time I captured both of these waveforms on the I2S bus, there was a headset plugged in, with a 346 Hz sine wave playing from a speaker a few inches away from it.

Here is what the AGC analysis window on the CodecControl application looks when that signal is applied to the microphone:

It doesn't look like much of a sine wave.  I am not sure why.  I have tried adjusting settings such as MIC_BIAS and microphone termination (registers 1:48, 1:49) and these do not seem to change anything substantially.

Here is what that same window looks when the sine wave signal is turned off:

As you can see from my Android_boot.txt script, the AGC settings during this test were:

# 0:83 -- ADCVOL: ADC coarse gain: 0 dB
w 30 53 00
# 0:86 -- AGCCTL1: AGC enabled, target level -10 dB
w 30 56 a0
# 0:87 -- AGCCTL2: 2 dB hysteresis, noise threshold -50 dB
w 30 57 54
# 0:88 -- AGCMAXGAIN: 40 dB maximum gain
w 30 58 50
# 0:89 -- AGCATTACK: 20 ms attack time
w 30 59 78
# 0:90 -- AGCDECAY: 500 ms decay time
w 30 5a b8
# 0:91 -- AGCNSDEB: 0 ms noise debounce time
w 30 5b 00
# 0:92 -- AGCDIDEB: 2 ms signal debounce time

I have tried a number of other AGC settings, and I have also tried turning off the AGC and adjusting the MIC_PGA (1:47) instead.

So the mysteries that I am trying to understand now are:

• Why do I not see something like a sine wave in the AGC analysis window, and
• Why can I not seem to get the input volume adjusted to affect more than a few of the LSB bits of the I2S signal ?

Any help you can provide would be greatly appreciated.

Thanks.

--ken

So you are now trying to recover or record the mic input from the headset which was inserted in your target board and you are trying to test this on EVM separately using the EVM on-board headset jack - is that correct?

Maybe can you provide a picture of your setup as previously you mentioned you can recover with the EVM, what changed?

"After configuration using the two scripts, the EVM can recover the audio signal from the microphone and put it on the I2S bus."

From the scope captured, is the blue line DOUT of the codec how about the Saleae data_input? It looks like this is a fix value of 0x0B.

Have you tried with different frequency say 1KHz tone and isolate it?

pduandi,

Yes, I am trying to recover audio from the headset mic input on the EVM board.  I must clarify what I wrote previously when I said "After configuration using the two scripts, the EVM can recover the audio signal from the microphone and put it on the I2S bus."  What I meant was that with a headset inserted into the EVM headset jack, and by monitoring the I2S bus, I could see all or nearly all of the 16 data bits changing in response to my voice as I was talking into the headset microphone.  However, I did not play this recovered signal.

At that time, the EVM was configured for 44.1 KHz and also was mastering the WCLK and BCLK signals, which is different than my target.  Also, the I2S bus was configured for 32 bits per channel instead of 16, also different than my target.  Also at that time, using the same register configurations except for the I2S interface configurations, I could not get this same behavior (i.e. all bits changing) on my target.

So, in an effort to understand this, I reconfigured the EVM by installing the 48 KHz firmware and setting SW2-4 to off in order to turn of the mastering of the WCLK and BCLK signals by the EVM.  Doing this, I was able to configure the I2S interface of the EVM the same as the target.  However, now I am unable to find a register configuration that can recover the audio signal to the full range on the I2S bus.

Also, previously I was only using my voice and was only concerned with getting a signal that appeared to correlate with my voice, and at that time was not looking at the integrity of the signal, so I had not tried recovering a sine wave.  I will reconfigure my EVM and try that now.

Here is a photo of my set-up on the EVM:

Yes, the blue trace of the scope is the receive data signal of the I2S bus; it is also shown on the Saleae logic analyzer.  If many more frames are viewed, the period of the received signal can be observed, but only the least significant four or five bits of the digital signal changes; if the sine wave is turned off the bus stays quiet with a nearly constant +10 to +11 value.

I have noticed that if I shout at the microphone or tap it with my finger, I can get spikes on the I2S bus that reach nearly the entire range.  But, I thought that the purpose of the AGC is to dynamically change the input gain when only low-volume signals are present, and then adapt the gain as the amplitude of the input signals increase.

Yes, I have also tried different frequencies of signals.

Here is what 1000 Hz looks like:

I also attached .csv files captured from my logic analyzer with different input gain settings:

1000_Hz_AGC_59.5dB_Max_Gain.csv -- Same settings as before except AGC maximum gain increased to 59.5 dB.

1000_Hz_MIC_PGA_59.5_AGC_MAX_GAIN_59.5.csv -- Same as above, except MIC PGA also set to 59.5 dB (normally 0 dB).

AGC_Off_MIC_PGA_59.5dB.csv -- Same as above, but AGC turned off (MIC PGA set to 59.5 dB).

1000_Hz_AGC_59.5dB_Max_Gain.csv

1000_Hz_MIC_PGA_59.5_AGC_MAX_GAIN_59.5.csv

AGC_Off_MIC_PGA_59.5dB.csv

Note that all reported values are positive (?).

The issue of primary concern at the moment is that the recovered signal is not a sine wave when a sine wave is present at the headset.

The secondary issue is configuring the input gain settings properly using AGC to best recover a range of signals of low to high volume.

Thanks.

--ken

Can you set your headset MIC input to MIC1RP instead of MIC1LP per the configuration shown below?

Also did you monitor the INT on your GPIO and it's indeed generating the interrupt when headset in inserted?

From the scope capture it looks like the codec has generated the correct BCLK and WCLK as master mode.

I believe right now there's no input so AGC is not behaving correctly.

pdjuandi,

Can I set my headset MIC input to MIC1RP instead of MIC1LP ... do you mean on my target board?  If yes, it is already set to MIC1RP.  Here is that part of the target schematic:

As far as I know, the EVM is getting a signal because I can see it when I click on the AGC block (see last image in my previous post).

By the way, I was just getting ready to ask you: how does the host computer running the CodecControl.exe application collect the raw signal into the AGC from the EVM?  I am not seeing any external circuitry on the EVM schematic that monitors the microphone input signal.

Unless there is some circuitry on the board that I don't know about I don't understand your last comment...

--ken

I'm sorry so with EVM you can see the I2S data change or signal is present but you are not able to record the sound level with MIC1LP as headset mic input? I'm not clear by your statement ".... recover the audio signal to the full range on the I2S bus." My impression of you not recovering means there's no MIC data captured/recorded by the I2S bus with MIC1LP, is this not true?

Let's make it simple just try on EVM and record the MIC1LP with just 1KHz tone using your settings above. Are you recording the 1KHz tone?

The AGC raw data is the ADC digital output of the analog input signal, there's no additional external circuitry.

pdjunadi,

Ok, I guess I am wrong, I am able to record the audio from the MICLP input on the EVM to a file and play it back; here it is:

1000_Hz.wma

However, my embedded system is not seeing the same data at the processor (or is not interpreting it properly); I will investigate and get back to you on that.

Meanwhile, I am still confused about how the ADC raw data is conveyed to the host computer.  I am seeing the noise signal in the AGC window even before the TLV320AIC3111 codec is configured, and I am not seeing any i2C activity or I2S activity during that time.  How is that signal data being captured and sent to the CodecControl.exe app?  Can I duplicate this on my target?

Thanks.

--ken

OK, so your setting works on EVM but not on your system - correct?

In EVM there's TAS1020 which is USB-Streaming controller IC which basically takes the I2S and convert to USB. That's how the host receive or transmit the audio data. 

Your target is using different controller so it will not work with the codec control GUI.

pdjuandi,

Right, I get that.  But there is no activity on the I2S bus on the EVM while at the same time I am seeing the noise signal in the AGC window.  That's what I don't understand.

--ken

If the device I2S bus is not routed to the TAS1020, those AGC plot is just random noise which the USB controller provided to host.

pdjuandi,

I ran three experiments with regard to this question about the AGC window:

(1)  I sent the commands to cause a software reset to the codec (w 30 00 00, w 30 01 01), and looked at the AGC window.  I could still see the noise signal.  Then I applied the 1000 Hz sine wave, and I could see the 1000 Hz signal in the AGC window, as before.

(2)  I disconnected the headset from the EVM, and re-executed the software reset.  I could see the noise signal.  Then I applied the 1000 Hz sine wave, and to my surprise, I then saw the 1000 Hz signal in the AGC window (!).

(3)  At this point, thoroughly confused, I disconnected the USB cable from the EVM (there is an external power supply providing power to the EVM).  I could see the noise signal, and also the 1000 Hz sine wave !!!

The only way I can explain this is that the signal feeding the AGC window of the CodecControl.exe application is the internal speaker of the computer.  If that is the case then the AGC settings are meaningless and I have been wasting quite a bit of time.

Meanwhile, on the target, I am now able to recover an audio signal from the headset microphone across the I2S bus.  So I have made progress on that front.

However, there are still a few problems:

(1)  The AGC is enabled but it is apparently overdriving the ADC.  I am getting continuous ADC overflow interrupts.  I have tried reducing the AGC maximum gain and I have made sure that the other receive gain settings are no more than 0 dB, but so far these adjustments do not seem to reduce the signal level.

(2)  The receive signal is not put on the I2S bus until I un-plug, and then re-insert the headset into the headset jack after I have started recording.  I am suspecting that this problem may be a function of the DAPM operations built into the Linux tlv320aic31xx driver.  The interesting thing is that all of the register contents are the same after the re-insertion as they were before the headset was unplugged, except for one register: 0:36 (ADC Flag Register).  The before value is 0xc0 while the after value is 0x60.  So the ADC gain appears to have saturated the ADC, which is consistent with problem (1).

Here is a dump of the registers of the TLV320AIC31111 codec while it is recording (after headset re-insertion):

tlv320aic31xx-codec 5-0018: page 0 reg 3 (0x03) : 0x56
tlv320aic31xx-codec 5-0018: page 0 reg 4 (0x04) : 0x03
tlv320aic31xx-codec 5-0018: page 0 reg 5 (0x05) : 0x91
tlv320aic31xx-codec 5-0018: page 0 reg 6 (0x06) : 0x08
tlv320aic31xx-codec 5-0018: page 0 reg 7 (0x07) : 0x07
tlv320aic31xx-codec 5-0018: page 0 reg 8 (0x08) : 0x80
tlv320aic31xx-codec 5-0018: page 0 reg 11 (0x0b) : 0x88
tlv320aic31xx-codec 5-0018: page 0 reg 12 (0x0c) : 0x82
tlv320aic31xx-codec 5-0018: page 0 reg 13 (0x0d) : 0x00
tlv320aic31xx-codec 5-0018: page 0 reg 14 (0x0e) : 0x80
tlv320aic31xx-codec 5-0018: page 0 reg 15 (0x0f) : 0x80
tlv320aic31xx-codec 5-0018: page 0 reg 16 (0x10) : 0x08
tlv320aic31xx-codec 5-0018: page 0 reg 18 (0x12) : 0x88
tlv320aic31xx-codec 5-0018: page 0 reg 19 (0x13) : 0x82
tlv320aic31xx-codec 5-0018: page 0 reg 20 (0x14) : 0x80
tlv320aic31xx-codec 5-0018: page 0 reg 21 (0x15) : 0x80
tlv320aic31xx-codec 5-0018: page 0 reg 22 (0x16) : 0x04
tlv320aic31xx-codec 5-0018: page 0 reg 25 (0x19) : 0x00
tlv320aic31xx-codec 5-0018: page 0 reg 26 (0x1a) : 0x01
tlv320aic31xx-codec 5-0018: page 0 reg 27 (0x1b) : 0x0c
tlv320aic31xx-codec 5-0018: page 0 reg 28 (0x1c) : 0x00
tlv320aic31xx-codec 5-0018: page 0 reg 29 (0x1d) : 0x0c
tlv320aic31xx-codec 5-0018: page 0 reg 30 (0x1e) : 0x88
tlv320aic31xx-codec 5-0018: page 0 reg 31 (0x1f) : 0x00
tlv320aic31xx-codec 5-0018: page 0 reg 32 (0x20) : 0x00
tlv320aic31xx-codec 5-0018: page 0 reg 33 (0x21) : 0x00
tlv320aic31xx-codec 5-0018: page 0 reg 34 (0x22) : 0x00
tlv320aic31xx-codec 5-0018: page 0 reg 36 (0x24) : 0x60
tlv320aic31xx-codec 5-0018: page 0 reg 37 (0x25) : 0x00
tlv320aic31xx-codec 5-0018: page 0 reg 38 (0x26) : 0x11
tlv320aic31xx-codec 5-0018: page 0 reg 39 (0x27) : 0x00
tlv320aic31xx-codec 5-0018: page 0 reg 44 (0x2c) : 0x00
tlv320aic31xx-codec 5-0018: page 0 reg 45 (0x2d) : 0x00
tlv320aic31xx-codec 5-0018: page 0 reg 46 (0x2e) : 0x10
tlv320aic31xx-codec 5-0018: page 0 reg 47 (0x2f) : 0x00
tlv320aic31xx-codec 5-0018: page 0 reg 48 (0x30) : 0xcc
tlv320aic31xx-codec 5-0018: page 0 reg 49 (0x31) : 0x00
tlv320aic31xx-codec 5-0018: page 0 reg 51 (0x33) : 0x16
tlv320aic31xx-codec 5-0018: page 0 reg 53 (0x35) : 0x12
tlv320aic31xx-codec 5-0018: page 0 reg 54 (0x36) : 0x03
tlv320aic31xx-codec 5-0018: page 0 reg 60 (0x3c) : 0x01
tlv320aic31xx-codec 5-0018: page 0 reg 61 (0x3d) : 0x04
tlv320aic31xx-codec 5-0018: page 0 reg 62 (0x3e) : 0x00
tlv320aic31xx-codec 5-0018: page 0 reg 63 (0x3f) : 0x14
tlv320aic31xx-codec 5-0018: page 0 reg 64 (0x40) : 0x0c
tlv320aic31xx-codec 5-0018: page 0 reg 65 (0x41) : 0x00
tlv320aic31xx-codec 5-0018: page 0 reg 66 (0x42) : 0x00
tlv320aic31xx-codec 5-0018: page 0 reg 67 (0x43) : 0xe9
tlv320aic31xx-codec 5-0018: page 0 reg 68 (0x44) : 0x6f
tlv320aic31xx-codec 5-0018: page 0 reg 69 (0x45) : 0x38
tlv320aic31xx-codec 5-0018: page 0 reg 70 (0x46) : 0x00
tlv320aic31xx-codec 5-0018: page 0 reg 81 (0x51) : 0x80
tlv320aic31xx-codec 5-0018: page 0 reg 82 (0x52) : 0x00
tlv320aic31xx-codec 5-0018: page 0 reg 83 (0x53) : 0x00
tlv320aic31xx-codec 5-0018: page 0 reg 86 (0x56) : 0xa0
tlv320aic31xx-codec 5-0018: page 0 reg 87 (0x57) : 0x54
tlv320aic31xx-codec 5-0018: page 0 reg 88 (0x58) : 0x00
tlv320aic31xx-codec 5-0018: page 0 reg 89 (0x59) : 0x78
tlv320aic31xx-codec 5-0018: page 0 reg 90 (0x5a) : 0xb8
tlv320aic31xx-codec 5-0018: page 0 reg 91 (0x5b) : 0x00
tlv320aic31xx-codec 5-0018: page 0 reg 92 (0x5c) : 0x07
tlv320aic31xx-codec 5-0018: page 0 reg 93 (0x5d) : 0x7f
tlv320aic31xx-codec 5-0018: page 0 reg 116 (0x74) : 0x00
tlv320aic31xx-codec 5-0018: page 0 reg 117 (0x75) : 0x7e
tlv320aic31xx-codec 5-0018: page 1 reg 30 (0x1e) : 0x00
tlv320aic31xx-codec 5-0018: page 1 reg 31 (0x1f) : 0x14
tlv320aic31xx-codec 5-0018: page 1 reg 32 (0x20) : 0x06
tlv320aic31xx-codec 5-0018: page 1 reg 33 (0x21) : 0x00
tlv320aic31xx-codec 5-0018: page 1 reg 34 (0x22) : 0x00
tlv320aic31xx-codec 5-0018: page 1 reg 35 (0x23) : 0x44
tlv320aic31xx-codec 5-0018: page 1 reg 36 (0x24) : 0x9b
tlv320aic31xx-codec 5-0018: page 1 reg 37 (0x25) : 0x9b
tlv320aic31xx-codec 5-0018: page 1 reg 38 (0x26) : 0x7f
tlv320aic31xx-codec 5-0018: page 1 reg 39 (0x27) : 0x7f
tlv320aic31xx-codec 5-0018: page 1 reg 40 (0x28) : 0x04
tlv320aic31xx-codec 5-0018: page 1 reg 41 (0x29) : 0x04
tlv320aic31xx-codec 5-0018: page 1 reg 42 (0x2a) : 0x00
tlv320aic31xx-codec 5-0018: page 1 reg 43 (0x2b) : 0x00
tlv320aic31xx-codec 5-0018: page 1 reg 44 (0x2c) : 0x20
tlv320aic31xx-codec 5-0018: page 1 reg 46 (0x2e) : 0x02
tlv320aic31xx-codec 5-0018: page 1 reg 47 (0x2f) : 0x00
tlv320aic31xx-codec 5-0018: page 1 reg 48 (0x30) : 0x10
tlv320aic31xx-codec 5-0018: page 1 reg 49 (0x31) : 0x40
tlv320aic31xx-codec 5-0018: page 1 reg 50 (0x32) : 0x00
tlv320aic31xx-codec 5-0018: page 3 reg 16 (0x10) : 0x8c

Any idea why the ADC is getting overdriven, or some other settings to change to mitigate this?

I am thinking that I can make some dynamic adjustments based on the ADC overflow interrupt, but I am not sure what adjustments to make.

Thanks.

--ken

It looks like you are running multiple systems on the same platform which causes this weird behavior. The AGC data is real time and it does not make sense when USB is unplug you can still run the GUI. The GUI will hang when you unplug the USB connector.

This just shows you are applying too much gain which causes the overflow.

pdjuandi,

Actually I ran these same three experiments on two different computers.  One is a Macbook Pro running Windows as a guest OS under VMWare virtualizer.  The other is a stand-alone Windows computer running Windows 10.  I captured a video of the experiment running on that second computer:

You can see in that video that the EVM USB cable is disconnected from the computer (even though the status on the screen says Connected), and when I talk, the waveform in the AGC window clearly follows my voice and its amplitude jumps above the noise level.  There is nothing else connected or running on that computer.

Regarding the "too much gain" problem, I am running the AGC with the following settings:

# Note: the following AGC configuration was added manually (not from i2c log)
# 0:83 -- ADCVOL: ADC coarse gain: 0 dB
w 30 53 00
# 0:86 -- AGCCTL1: AGC enabled, target level -10 dB
w 30 56 a0
# 0:87 -- AGCCTL2: 2 dB hysteresis, noise threshold -50 dB
w 30 57 54
# 0:88 -- AGCMAXGAIN: 0 dB maximum gain
w 30 58 00
# 0:89 -- AGCATTACK: 20 ms attack time
w 30 59 78
# 0:90 -- AGCDECAY: 500 ms decay time
w 30 5a b8
# 0:91 -- AGCNSDEB: 0 ms noise debounce time
w 30 5b 00
# 0:92 -- AGCDIDEB: 2 ms signal debounce time

It seems that the gain is already at a minimum level (?).

I will try reducing the target level; I guess that can be dropped up to another 14 dB.

--ken

Attaching video again, this time from my phone…

I'm not sure why it's showing that on your system.

I tried on my setup with no input, with 1Khz tone and and when USB disconnected (GUI disconnected/blank) as shown below.

It's not just the AGC gain but the path.