I2S is not output correctly

Hi,

  As per the post - "Lch is not output correctly sometimes occur" - Is this happening sometimes, Can they share the snapshot of the passing scenario as well.

  I understand that this is their custom board, what is I2S2 interfaced to? Can they check and confirm no anomalies with respect to this I2S interface,  

  I checked the I2S configuration and it looks ok.  They could also try running I2S CSL example, this will help isolate any software issues..

Regards

 Vasanth

Hi, Vasanth

Thank you for your reply, and sorry for late reply.

This problem is happening sometimes, I will share the other snapshot as follow.

I2S2 of customer board is connected to the audio codec, C5517:I2S2_DX to Audio Codec:RX pin.

I have ran their code in the EVM of C5517 problem did not occur,
so, I also think that their I2S settings and software is no issue.

We are able to share schematics of customer board by our Local TI FAE.
Could you please check the schematics?

Best regards,
H.U

Hi,

Based on your inputs its becoming quite clear that software is OK but looks issue exists with their hardware (custom board).

I would like to make the following recommendations.

1. I understood that the other I2S (I2S0/3) on their board works fine, can they check for any differences with I2S2 interface when compared to other I2S0 or I2S3 ?.

2. Review their custom board against C5517 EVM schematics and check for any discrepancies.

3. Is the RC circuit delay as specified in the TRM taken care (Applicable in slave mode) ? – “Synchronization issues may occur if the frame clock transitions close to the falling edge of the bit clock violating the previously described hold requirement resulting in incorrect data transfer. In these circumstances, the frame clock should be delayed with respect to the bit clock by introducing a time delay in its signal path. The RC circuit delays the frame clock by a value given by the   relation Trc = RC”

Regards

Vasanth

Hi, Vasanth

Hi,

Thanks for sharing further details.

With respect to customer response on I2S2 in loopback mode – “tried to check the internal loopback mode with I2S2. the receive data is not correctly. So, it seems that this problem is C5517 internal issue “

We haven’t observed any such issue on I2S2. I would suggest to run the same code on C5517 EVM, this would help isolate the issue. Hope they have C5517 EVM. 

Also, can you help answer few more questions: Did customer try run the same code (internal loopback ) on other I2S interface ? is it working correctly ? Did they try this on multiple boards ? is the same issue been observed on multiple boards ?

Regards

Vasanth

Hi, Vasanth

Our loopback test details are shown below:
I2S2 output data : 0xf0f0 for Lch, 0xffff for Rch
I2S2 input data : mostly received data is correct, but sometimes(about once every 10 times) 0xffff is received at Lch and 0xf0f0 is received at Rch.

Please see attached file(main.c)

volatile signed short debug_sound_buf[2][256];
volatile unsigned short debug_sound_buf_index;

//volatile signed short debug_sound_txdat;


/*----------------------------------------------*/
/* I2S2 TX Interrupt (ISR)						*/
interrupt void i2s_tx_isr(void)
{
	volatile unsigned short dummy;

	dummy =(* (volatile unsigned int *)(0x2A10) ); 
	
	(* (ioport unsigned short *)(0x2A09) ) = (unsigned short)(0xf0f0);		/* I2STXLT2 (upper) */
	(* (ioport unsigned short *)(0x2A08) ) = 0xffff;							/* I2STXLT1 (lower) */
			
	(* (ioport unsigned short *)(0x2A0D) ) = (unsigned short)(0xffff);		/* I2STXRT2 (upper)*/
	(* (ioport unsigned short *)(0x2A0C) ) = 0xffff;								/* I2STXRT1 (lower) */

//	debug_sound_txdat = (debug_sound_txdat + 1) & 7;
}


/*----------------------------------------------*/
/* I2S2 RX Interrupt (ISR)						*/
interrupt void i2s_rx_isr(void)
{

	volatile unsigned short dummy;
	
	dummy = (* (ioport volatile unsigned int *)(0x2A10) ); 

	debug_sound_buf[0][debug_sound_buf_index] =  (* (ioport volatile unsigned int *)(0x2A29) );
	dummy = (* (ioport volatile unsigned int *)(0x2A28) );

	debug_sound_buf[1][debug_sound_buf_index] =  (* (ioport volatile unsigned int *)(0x2A2D) );
	dummy = (* (ioport volatile unsigned int *)(0x2A2C) );

	debug_sound_buf_index = ((debug_sound_buf_index + 1) & 255);	/* buffer index increment (from 0 to 255) */
}


/*----------------------------------------------*/
/*	Main										*/
void main(void)
{
	unsigned short tmp;

	_disable_interrupts();
	
	/* Interrupt Initialize */	
	(* (volatile unsigned short *)0x0001 ) = 0xFFFF;	/* IFR0 */
	(* (volatile unsigned short *)0x0046 ) = 0xFFFF;	/* IFR1 */
		
	(* (volatile unsigned short *)0x0000 ) = 0x0000;	/* IER0 */
	(* (volatile unsigned short *)0x0045 ) = 0x0000;	/* IER1 */

	
//	if((CPU.IVPD != BOOT_IVP) || (CPU.IVPH != BOOT_IVP)) {
//		r = 0;
//	}
	
	(* (volatile unsigned short *)0x0049 ) = 0x0001;		/* IVPD Interrupt Address -> 0x000100 */
	(* (volatile unsigned short *)0x004A ) = 0x0001;		/* IVPH Interrupt Address -> 0x000100 */

	/* PLL off, Bypass Mode */
	(* (ioport volatile unsigned short *)0x1C1F ) = 0x0000;		/* CCR2 Register */

	/* Wait Bypass Mode (4Cycles) */
	asm( "      repeat(#4) ");					/* Wait 4Cycles */
	asm( "		NOP" );
	/* PLL reset �z�[���h */
	
	(* (ioport volatile unsigned short *)0x1C22 ) = 0x4000;		/* PCR Register */

	/* Set PLL Parameter  */
	(* (ioport volatile unsigned short *)0x1C20 ) = 16128;				/* PMR Register */
	(* (ioport volatile unsigned short *)0x1C21 ) = 0x0001;				/* PICR Register */
	(* (ioport volatile unsigned short *)0x1C23 ) = 0x0000;			/* PODCR Register */

	/* PLL reset release */
	(* (ioport volatile unsigned short *)0x1C22 ) = 0x0000;

	/* wait 4ms for PLL stabilization  */
	/* wait 4ms  (49152cycle at 12.288MHz clock frequency) */
	asm( "      repeat(#49152) ");					/* Wait Cycles 81ns * 49152=4ms */
	asm( "		NOP" );

	/* PLL on */
	(* (ioport volatile unsigned short *)0x1C1F ) = 0x0001;

	/* ST3_55 CLKOFF bit  */
	tmp = (* (volatile unsigned short *)0x0004 );
	tmp |= 4;	/* write 1 to clkoff bit */
	(* (volatile unsigned short *)0x0004 ) = tmp;

//	(* (ioport volatile unsigned short *)0x1C24 ) = 0x8001;	/* CLKOUTCR */
	(* (ioport volatile unsigned short *)0x1C24 ) = 0x8000;	/* CLKOUTCR */

	/* EBSR setting */
	(* (ioport volatile unsigned short *)0x1C00 ) = 0x153c;

	/* Clock Gating */
	(* (ioport volatile unsigned short *)0x1C02 ) = 0x34F9;
	(* (ioport volatile unsigned short *)0x1C03 ) = 0x003d;

	(* (ioport volatile unsigned short *)0x1C04 ) = 0x0008;
	(* (ioport volatile unsigned short *)0x1C05 ) = 0x00ff;
	asm( "      repeat(#8)");					/* Wait Cycles 81ns * 49152=4ms */
	asm( "		NOP" );

	
	
	/* I2s2 Setting */
	(* (ioport volatile unsigned short *)0x2A00 ) = 0x0822;			/* I2S2SCTRL */
	(* (ioport volatile unsigned short *)0x2A04 ) = 0x001d;			/* I2S2SRATE */
														/* bit clock = 196.608MHz / 64 = 3.072MHz,  frame = 3.072MHz / 64 = 48kHz  */
	
	(* (ioport volatile unsigned short *)0x2A14 ) = 0x0028;			/* I2S2INTMASK */

	tmp = (* (ioport volatile unsigned short *)0x2A00 );			/* I2S2SCTRL  */
	tmp |= 0x8000;													/* enable bit ON */
	(* (ioport volatile unsigned short *)0x2A00 ) = tmp;	
	
	tmp = (* (volatile unsigned short *)0x0000 );			/* IER0 */
	tmp |= 0xC000;											/* RCV2 bit ON , XMT2 bit ON */
	(* (volatile unsigned short *)0x0000 ) = tmp;

	debug_sound_buf_index = 0;								/* initialize buffer index */
//	debug_sound_txdat = 0;									/* initialize tx data for loopback */

	_enable_interrupts();
	
	
	while(1);

}

I2S0 and I2S3 of customer board was not happening such problem with same loopback test code.

and this problem did not occur in EVM with their code, I2S2 of EVM receive data was correct.

Customer has made 10 target boards in total.
They tested the 2 boards, the problem of I2S2 has been observed on these boards.
Other boards are not tested, currently these boards are using in order to other function test.

Best regards,
H.U

Hi,

Can they try on other board too. Unless it’s recreated on any of the TI platform it would be difficult to debug the issue.

Since code works on other I2S (I2S0 & I2S3) and on C5517 EVM I do not think this is a device issue. More over with respect to I2S, it would be the same IP with multiple instances, so not suspecting this.

Few more suggestion:

For testing purpose possibly change other parameters like CLKPOL etc or if possible  try with different sampling rate ?  Just to check whether this makes any difference.

Try use CSL code - Modify the existing CSL example code to match current requirement and verify once ? ( As they are seeing their code worked on EVM C5517 his may not be high point of interest).

Regards

 Vasanth

Hi, Vasanth

Thank you for your reply, and sorry for late response.

>Can they try on other board too.

They tried on additional two their boards, The same problem has occurred with these boards.

>Try use CSL code - Modify the existing CSL example code to match current requirement and verify once ? ( As they are seeing their code worked on EVM C5517 his may not be high point of interest).

I am currently confirming that.

I descrived below the new information that was found.

- Change the sampling rate(half rate) : The same problem has occurred
- Change the clock polarity(I2S2SCTRL.CLKPOL = 0 --> 1) : The problem has not occurred
- Change the data delay(I2S2SCTRL.DATADLY = 0 --> 1) : The problem has not occurred
- Change the data format(I2S2SCTRL.FRMT = 0 --> 1) : The problem has not occurred

It is very inexplicable phenomenon, so we are stuck.
Would you be able to investigate their board review?
I sent the schematic of customer board to local TI FAE, Please contact them.

Best regards,
H.U