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.

ADS8328 sound bleeding over to other channel TMS320F28335

Other Parts Discussed in Thread: TMS320F28335, ADS8328, TEST2

I have an ADS8328 hooked up to the McBSP of my TMS320F28335 and am using it to read in from two different audio sources. I have designed a small library that initializes the device into Manual Trigger, Manual Channel Select mode and allows me to read from a given channel (0 or 1) and write to it to configure. 

For some reason, when I try to read in from one channel and then immediately read in from the other channel. The sounds of one channel bleeds into another. This makes me wonder if I have a timing issue and if I am actually getting a correct signal for even one  channel. I was wondering if someone could look at my library and see if something looks off.

Here is my write function:

// Writes a value to the ADC
static void ADS8328_Write(unsigned int value)
{
	while(!McbspbRegs.SPCR2.bit.XRDY);	// Wait until transmit register is ready
	McbspbRegs.DXR1.all = value;
}

Here is my initialization:

// Initializes the ADS8328 to run in manual trigger, manual channel selection.
unsigned int ADS8328_Init()
{
	EALLOW;
	GpioCtrlRegs.GPAMUX2.all &= 0xFF00FFFF;	//clear location for MCBSP
	GpioCtrlRegs.GPAMUX2.all |= 0x00FF0000;	//select MDRB,MDXB,MCLKXB,MFSXB

	McbspbRegs.SPCR2.all=0x0000;		// Reset FS generator, sample rate generator & transmitter
	McbspbRegs.SPCR1.all=0x0000;		// Reset Receiver, Right justify word

	McbspbRegs.SPCR1.bit.CLKSTP = 2;		// Set to clock stop mode
	McbspbRegs.PCR.bit.CLKXP = 0;        // CPOL = 0, CPHA = 0 rising edge no delay
	McbspbRegs.PCR.bit.CLKRP = 0;

	McbspbRegs.PCR.bit.CLKXM = 1;		// CLKX generated internally, CLKR derived from an external source
	McbspbRegs.PCR.bit.SCLKME = 0;
	McbspbRegs.SRGR2.bit.CLKSM = 1;		// CLKSM=1 (If SCLKME=0, i/p clock to SRG is LSPCLK)
	McbspbRegs.SRGR1.bit.CLKGDV = 1;	// CLKG frequency = LSPCLK/(CLKGDV+1)
	McbspbRegs.PCR.bit.FSXM = 1;		// FSX generated internally, FSR derived from an external source
	McbspbRegs.SRGR2.bit.FSGM = 0;		// FSX pulses every time data is transferred from DXR1 to XSR1
	McbspbRegs.PCR.bit.FSXP = 1;		// FSX is active low

	McbspbRegs.XCR2.bit.XDATDLY = 1;	// Transfer delay = 1 (for master mode)
	McbspbRegs.RCR2.bit.RDATDLY = 1;	// Recieve delay = 1 (for master mode)

	McbspbRegs.XCR1.bit.XFRLEN1 = 0;	// transmit frame length = 1 word
	McbspbRegs.XCR1.bit.XWDLEN1= 2;     // 16-bit word

	McbspbRegs.RCR1.bit.RFRLEN1 = 0;	// recieve frame length = 1 word
	McbspbRegs.RCR1.bit.RWDLEN1= 2;     // 16-bit word

	McbspbRegs.SPCR2.bit.GRST=1; // Enable the sample rate generator
	delay_loop();                // Wait at least 2 SRG clock cycles
	McbspbRegs.SPCR2.bit.XRST=1; // Release TX from Reset
	McbspbRegs.SPCR1.bit.RRST=1; // Release RX from Reset
	delay_loop();
	McbspbRegs.SPCR2.bit.FRST=1; // Frame Sync Generator reset
	delay_loop();

	GpioCtrlRegs.GPAMUX1.bit.GPIO8 = 0;	// GPIO8  is the INT signal
	GpioCtrlRegs.GPAMUX1.bit.GPIO9 = 0; // GPIO9 is the CONVST signal
	GpioCtrlRegs.GPADIR.bit.GPIO8 = 0;
	GpioCtrlRegs.GPADIR.bit.GPIO9 = 1;
	GpioDataRegs.GPADAT.bit.GPIO9 = 1;

	ADS8328_Write(0xE7BD);			// sets mode to use
	delay_loop();

	EDIS;

	return 0;
}

Here is my read function:

// Reads a channel of the ADC
int ADS8328_Read(channel c)
{
	ADS8328_Write(c);					// select channel
	while(!McbspbRegs.SPCR1.bit.RRDY);     	// Master waits until RX data is ready
	GpioDataRegs.GPACLEAR.bit.GPIO9 = 1; // set CONVST low
	GpioDataRegs.GPASET.bit.GPIO9 = 1;   // set CONVST high
	while(!GpioDataRegs.GPADAT.bit.GPIO8); // Wait for trigger
	ADS8328_Write(0xD000);
	while(!McbspbRegs.SPCR1.bit.RRDY);     	// Master waits until RX data is ready

	return (McbspbRegs.DRR1.all - dcOffset);
}

Here is a case where this "bleeding" occurs

int x = ADS8328_Read(CHANNEL1);
int y = ADS8328_Read(CHANNEL0);

DAC8830_Write(x);

Here x will get filled with some audio from Channel 0

Any ideas?

  • Hi Raz,

    Can I suggest a debug strategy? Try supplying channel 0 with a DC voltage, say 1.0V, and channel 1 with a different DC voltage, say 2.0V. Now after you initialize the communications channel, record different sequences of reads to drill down into exactly what the issue is?

    e.g.
    //test1
    Uint16 results[20];
    <initialize results to all 0s>
    results[0] = ADS8328_Read(CHANNEL1);

    //test2
    Uint16 results[20];
    <initialize results to all 0s>
    results[0] = ADS8328_Read(CHANNEL0);

    //test3
    Uint16 results[20];
    <initialize results to all 0s>
    results[0] = ADS8328_Read(CHANNEL0);
    results[1] = ADS8328_Read(CHANNEL0);

    //test4
    Uint16 results[20];
    <initialize results to all 0s>
    results[0] = ADS8328_Read(CHANNEL1);
    results[1] = ADS8328_Read(CHANNEL1);

    //test5
    Uint16 results[20];
    <initialize results to all 0s>
    results[0] = ADS8328_Read(CHANNEL1);
    results[1] = ADS8328_Read(CHANNEL0);

    //test6
    Uint16 results[20];
    <initialize results to all 0s>
    results[0] = ADS8328_Read(CHANNEL0);
    results[1] = ADS8328_Read(CHANNEL1);

    ... until you can definitively say the problem occurs only when ___.

    (you would want to reset and re-load the code for each test)
  • I only did three of the tests because of the strange results I got

    Results:

    Channel0 has 3V DC
    Channel1 has 2V DC

    Test 1: results[0] = Read Channel0
    First 1 or 2 two values are incorrect. Rather they are past ADC values.

    Test 2: results[0] = Read Channel1
    Same results as Test 1

    Test 3: results[0] = Read Channel0; results[1] = Read Channel0
    results[0] oscillates between Channel1! (2V) and 0 --very strange
    results[1] has the pattern of 0, Channel0, 0, Channel1 --also very strange

    Definitely seems like I have some major timing issue with my code.
  • Raz,

    Yeah, I think the next step is probably to inspect the timings with a 'scope or logic analyzer. You can use the same tests as above...start with a single read to one channel, and see what is actually flying around on the bus and how long the signals strobe. If you get one read working, next inspect the timings for back-to-back reads.