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.

Why no Right channel on DOUT?

Other Parts Discussed in Thread: TLV320AIC3254, TLV320AIC3254EVM-K

Hello,


I have a circuit which feeds a mic input to IN3L and IN3R

0x013368,  //# reg[  1][ 51] = 0x68    ; Mic Bias powered on, MICBIAS is 2.5V and generated from LDOIN
0x013404,  //# reg[  1][ 52] = 0x04    ; Route IN3L to LEFT_P with 10K input impedance
0x013640,  //# reg[  1][ 54] = 0x40    ; Route CM1L to LEFT_N with 10K input impedance
0x013704,  //# reg[  1][ 55] = 0x04    ; Route IN3R to RIGHT_P with 10K input impedance
0x013940,  //# reg[  1][ 57] = 0x40    ; Route CM1R to RIGHT_N with 10K input impedance
0x013B28,  //# reg[  1][ 59] = 0x28    ; Unmute Left MICPGA, Gain selection of 20dB for microphone
0x013C28,  //# reg[  1][ 60] = 0x28    ; Unmute Right MICPGA, Gain selection of 20dB for microphone
0x0051C0,  //# reg[  0][ 81] = 0xC0    ; Power up LADC/RADC
0x005200,  //# reg[  0][ 82] = 0x00    ; Unmute LADC/RADC

I would think that this would give me the same signal on both channels yet my right channel of DOUT is always 0x0000.

Any help would be appreciated.

Thank you,

  • Hi Angelo,

    What part are you working with? It seems you might have tried to post some images, but they are not loading for me. Otherwise I don't see a mention of which part you are using.

    Justin
  • Sorry about that Justin.

    I am working with a TLV320AIC3254.

    I had pasted images in the post but I guess that doesn't work.

    1 image was showing a MICin signal going to IN3L and IN3R via 10uF cap on each pin. It also had a 2.2KOhm resistor to MICBIAS connected to MICin.

    The second image was just a logic trace showing I2S data on channel 2 and always 0 on channel 1.

    For what I am working on it is fine if I only have one channel but I am trying to understand why it is like that.

    Thank you,
    Angelo
  • Hello Angelo,
    Make sure you are using a stereo processing block. Search PRB_R in the TLV320AIC3254 datasheet and application reference guide. The GUI software has several example scripts you can refer to. It can be downloaded on the TLV320AIC3254EVM-K website.
    Regards,J-
  • Hi J,

    I am using PRB_R1 (reg[0][61]=0x01)

    I noticed that some examples set it to 0x00 (Is this with no filtering at all?) however I notice in the spec that PRB_R1 is stereo wiith a filter.

    More Info:

    I initialize the AIC3254 by:
    1. Writing the following
    0x000000,
    0x000101, //# reg[ 0][ 1] = 0x01 ; Initialize the device through software reset
    0xFE000A, //# reg[254][ 0] = 0x0a ; Delay 10ms
    0x010209, //# reg[ 1][ 2] = 0x09 ; Disable Master Analog Power Control, Power up AVDD LDO
    0x010108, //# reg[ 1][ 1] = 0x08 ; Disable weak AVDD to DVDD connection
    0x010201, //# reg[ 1][ 2] = 0x01 ; Enable Master Analog Power Control, AVDD LDO Powered
    0x013D00, //# reg[ 1][ 61] = 0x00 ; Select ADC PTM_R4
    0x014732, //# reg[ 1][ 71] = 0x32 ; Set the input power-up time to 3.1ms
    0x017B01, //# reg[ 1][123] = 0x01 ; Set REF charging time to 40ms (automatic)

    2. waiting 125ms

    3. writing to miniDSP_A_Coeff 0x0000 from image file
    4. writing to miniDSP_A_Coeff 0x0100 from image file
    5. writing to miniDSP_A_Instr
    6. writing to miniDSP_D_Coeff 0x0000 from image file
    7. writing to miniDSP_D_Coeff 0x0100 from image file
    8. writing to miniDSP_D_Instr

    9. wait about 135ms
    10. write the following

    0x003C00, //# reg[ 0][ 60] = 0x00 ; DAC prog Mode: miniDSP_A and miniDSP_D NOT powered up together, miniDSP_A used for signal processing
    0x003D01, //# reg[ 0][ 61] = 0x01 ; Use miniDSP_A for signal processing
    0x001108, //# reg[ 0][ 17] = 0x08 ; 8x Interpolation
    0x001704, //# reg[ 0][ 23] = 0x04 ; 4x Decimation
    0x000F03, //# reg[ 0][ 15] = 0x03
    0x001088, //# reg[ 0][ 16] = 0x88
    0x001503, //# reg[ 0][ 21] = 0x03
    0x001688, //# reg[ 0][ 22] = 0x88
    0x080104, //# reg[ 8][ 1] = 0x04 ; adaptive mode for ADC
    0x2C0104, //# reg[ 44][ 1] = 0x04 ; adaptive mode for DAC
    0x000443, //# reg[ 0][ 4] = 0x43 ; PLL_clkin = MCLK, codec_clkin = PLL_CLK,
    0x000591, //# reg[ 0][ 5] = 0x91 ; PLL on, P=1, R=1, J=5,
    0x000605, //# reg[ 0][ 6] = 0x05 ; PLL on, P=1, R=1, J=5,
    0x00070E, //# reg[ 0][ 7] = 0x0E ; D=3760 (MSB)
    0x0008B0, //# reg[ 0][ 8] = 0xB0 ; D=3760 (LSB)
    0x000B82, //# reg[ 0][ 11] = 0x82 ; NDAC = 2, dividers powered on
    0x000C87, //# reg[ 0][ 12] = 0x87 ; MDAC = 7, dividers powered on
    0x000D00, //# reg[ 0][ 13] = 0x00 ; DOSR = 128 (MSB)
    0x000E80, //# reg[ 0][ 14] = 0x80 ; DOSR = 128 (LSB)
    0x001282, //# reg[ 0][ 18] = 0x82 ; NADC = 2 powered on
    0x001387, //# reg[ 0][ 19] = 0x87 ; MADC = 7 powered on
    0x001480, //# reg[ 0][ 20] = 0x80 ; AOSR = 128
    0x001D02, //# reg[ 0][ 29] = 0x02 ; BCLK frequency is generated from ADC_CLK
    0x001E9C, //# reg[ 0][ 30] = 0x9C ; Divider = 28
    0x001BCC, //# reg[ 0][ 27] = 0xCC ; Set BCLK and WCLK as outputs LEFT Justified
    0x001C01, //# reg[ 0][ 28] = 0x01 ; BCLK offset by 1
    0x013368, //# reg[ 1][ 51] = 0x68 ; Mic Bias powered on, MICBIAS is 2.5V and generated from LDOIN
    0x013404, //# reg[ 1][ 52] = 0x04 ; Route IN3L to LEFT_P with 10K input impedance
    0x013640, //# reg[ 1][ 54] = 0x40 ; Route CM1L to LEFT_M with 10K input impedance
    0x013704, //# reg[ 1][ 55] = 0x04 ; Route IN3R to RIGHT_P with 10K input impedance
    0x013940, //# reg[ 1][ 57] = 0x40 ; Route CM1R to RIGHT_M with 10K input impedance
    0x013B28, //# reg[ 1][ 59] = 0x28 ; Unmute Left MICPGA, Gain selection of 20dB for microphone
    0x013C28, //# reg[ 1][ 60] = 0x28 ; Unmute Right MICPGA, Gain selection of 20dB for microphone
    0x0051C0, //# reg[ 0][ 81] = 0xC0 ; Power up LADC/RADC
    0x005200, //# reg[ 0][ 82] = 0x00 ; Unmute LADC/RADC
    0x011425, //# reg[ 1][ 20] = 0x25 ; De-pop: 5 time constants, 6k resistance
    0x010C08, //# reg[ 1][ 12] = 0x0A ; Route LDAC and MAL to HPL
    0x010D08, //# reg[ 1][ 13] = 0x0A ; Route RDAC and MAR to HPR
    0x010A03, //# reg[ 1][ 10] = 0x03 ; Output of HPL and HPR is powered with LDOIN supply, LDOIN input range is 1.8V to 3.6V
    0x011824, //# reg[ 1][ 24] = 0x22 ; -22.1dB Left Mixer amp volume
    0x011924, //# reg[ 1][ 25] = 0x22 ; -22.1dB Right Mixer amp volume
    0x010930, //# reg[ 1][ 9] = 0x33 ; Power up HPL/HPR and MAL/MAR
    0x011000, //# reg[ 1][ 16] = 0x00 ; Unmute HPL/HPR driver, 0dB Gain
    0x011100, //# reg[ 1][ 17] = 0x00 ;
    0x004100, //# reg[ 0][ 65] = 0x00 ; DAC => 0dB
    0x004200, //# reg[ 0][ 66] = 0x00 ;
    0x003FD4, //# reg[ 0][ 63] = 0xD4 ; Power up LDAC/RDAC
    0x004000, //# reg[ 0][ 64] = 0x00 ; Unmute LDAC/RDAC
    0x005200, //# reg[ 0][ 82] = 0
    0x005300, //# reg[ 0][ 83] = 0
    0x005620, //# reg[ 0][ 86] = 32
    0x0057FE, //# reg[ 0][ 87] = 254
    0x005800, //# reg[ 0][ 88] = 0
    0x005968, //# reg[ 0][ 89] = 104
    0x005AA8, //# reg[ 0][ 90] = 168
    0x005B06, //# reg[ 0][ 91] = 6
    0x005C00, //# reg[ 0][ 92] = 0
    0x005400, //# reg[ 0][ 84] = 0
    0x005E20, //# reg[ 0][ 94] = 32
    0x005FFE, //# reg[ 0][ 95] = 254
    0x006000, //# reg[ 0][ 96] = 0
    0x006168, //# reg[ 0][ 97] = 104
    0x0062A8, //# reg[ 0][ 98] = 168
    0x006306, //# reg[ 0][ 99] = 6
    0x006400 //# reg[ 0][100] = 0

    Notice that the mixer Amp is effectively disabled. I was using the MAL and MAR to make sure that the mic signal was reaching both IN3L and IN3R. Which it does I hear on both HPL and HPR.

    The other reason I was doing this is because I would like to inject a bit of mic input into the headphone. I tried that by using a stereo splitter of the mic input and using a stereo mixer to mix the one of the stereo outputs of the splitter with the I2SIN before sending it to the headset and that didn't work. so I did it via analog bypass

    This makes me think that both issues are related to something I am doing in the DSP.

    However, I can control the volume on the fly via the following code:

    if(ParamMode == VOLUME_MODE)
    {
    VolumeIndex = Index;
    AIC3254_I2C_PAGE_WRITE(MV_Reg, MV_Page, &(AIC3254_Volume1[100 - VolumeIndex]), 4); // Write Volume
    AIC3254_I2C_WRITE(0x01, 0x05); //Write 5 to page 44 reg 1
    while(AIC3254_I2C_READ(0x01)&0x01); //Wait for D0 of Page 44 reg 1 to be zero
    AIC3254_I2C_PAGE_WRITE(MV_Reg, MV_Page, &(AIC3254_Volume1[100 - VolumeIndex]), 4); // Write Voliume again
    }

    Thanks,
    Angelo
  • Angelo,
    Looks like you are using an image generate by PurePath Studio. In such case, simply start off by using the entire data structure generated by PurePath. This uses mode 0 (miniDSP mode). So register 61 must be 0x00 in such case. Because coefficient ram is shared for both PRB mode and miniDSP mode, PRB will not work properly if you download miniDSP mode coefficients.
    The MAL and MAR are use for analog bypass and not for DSP processing.
    My recommendation is to start with a simple script from here: http://www.ti.com/lit/pdf/slaa404 in PRB mode to make sure everything works. Then, once you make sure it is working set it in miniDSP mode.
    Regards,J-
  • Hi J

    Thank you for your response.
    I have solved my many issues by changing the miniDSP_A_cycles and miniDSP_D_cycles allocated from 904 to 400 after looking at the resource view and seeing that the actual cycles used are 198 and 319 respectively.

    I am not actually sure why this solved all my issues:
    I now have a right channel,
    I can use the recommended Dec4x_In at a gain of 0dB instead of Dec1x_in with a 20dB gain on micPGA.
    Also it now works to set register 61 to 0x00 as you recommended and as the default framework was set in PPS.
    When I make a change in pure path I see the effect of that change.

    It seems that most of the impact was on the Analog side.

    BTW in PPS regarding miniDSP_X_cycles it says:

    The upper limit is equal to clock rate/ sampling rate. Tip: Use View->Resource Window in GDE to check resource usage of a process flow.

    What clock rate are they talking about is it ADC_CLK and DAC_CLK?

    If so then I am still confused because my ADC_CLK = DAC_CLK = 43.008MHz
    at a sampling rate of 48kHz = 896 which is less than the original allocation of 904.

    In conclusion the problem appears solved by reducing the miniDSP_X_cycles but the exact reason is not clear to me.

    Any info you have to clarify this would be appreciated.

    Thank you,
    Angelo
  • HI Angelo,

    Please refer to the following FAQs:

    http://e2e.ti.com/support/data_converters/audio_converters/w/design_notes/1098.aic3254-minidsp-d-cycles-and-minidsp-a-cycles

    http://e2e.ti.com/support/data_converters/audio_converters/w/design_notes/1097.what-is-the-purpose-of-p0-r60-b7-6-in-aic3254

    http://e2e.ti.com/support/data_converters/audio_converters/w/design_notes/2777.modifying-the-configuration-script-of-a-pps-process-flow

    Make sure the Sync mode property of the framework is disabled. Using a higher # cycles should not be a problem. By default, for 48ksps, MDAC*DOSR = 1024, so all the cycles settings you mentioned are valid, assuming you use the corresponding Dec and Int components to the framework you selected.

    My recommendation is to start off placing the 8x4x framework, Int8x and Dec4x component from scratch without modifying the SystemSettingsCode.

    Regards,

    Jorge