TMS320C6727: DMAX read through McASP random behavior

Please share which Processor SDK RTOS are you using.

Best Regards,
Yordan

Hi Yordan, 

I'm using DSP/BIOS v5.42.1.09 with TI v6.1.11 compiler version.

Kind regards

Aurélien

Aurelien,

This is a 15 year old DSP where we don`t have too many experts left who have programmed the DMAX interface. Can you indicate if this is new development or you are trying to revive old code for a new project. Is the DMAX/MCASP code provided by TI or custom code that has been used on your product. Usually if most of the data is received correctly and some data is shifted/rotated then it indicates a timing issue. can you confirm that the data[9] and data[10] are occurring on the MCASP time slot correctly ? is the data truely rotated or right shifted where the last bit is missed or not shifted into the mcasp register. does the mcasp status register indicate any under run errors in MCASP_RXSTAT? Does the 1 bit shift occur consistently or occurs occasionally in your setup. Is the MCASP setup in TDM mode with 13 time slots ? Have you tried to see if the clock polarity is affecting the setup. What is the value of MCASP_RXFMT[2:0] that determines if the data is rotated.

Again, it is unclear why only data[9] and data[10] are shifted. Do have scope shot of this as it appears on the MCASP serializer and how the clock appears when the data appears on the serializer.

Regards,
Rahul

Hi Rahul,

Rahul Prabhu said:

This is a 15 year old DSP where we don`t have too many experts left who have programmed the DMAX interface. Can you indicate if this is new development or you are trying to revive old code for a new project.

This is a new project which will upgrade an existing one. The DSP code gets new functionalities but the basics is the older project with some tweeking on interfaces.

Rahul Prabhu said:

Is the DMAX/MCASP code provided by TI or custom code that has been used on your product.

Custom code.

Rahul Prabhu said:

Usually if most of the data is received correctly and some data is shifted/rotated then it indicates a timing issue. can you confirm that the data[9] and data[10] are occurring on the MCASP time slot correctly ?

If I don't use the DMAX and pool the RSTAT0 register with an infinite loop at the end of main, there isn't any error on the McASP reception.

Rahul Prabhu said:

is the data truely rotated or right shifted where the last bit is missed or not shifted into the mcasp register.

The data is rotated 1 bit on the right.

Rahul Prabhu said:

does the mcasp status register indicate any under run errors in MCASP_RXSTAT?

No "overrun" error, the register is equalt to 0x106

Rahul Prabhu said:

Does the 1 bit shift occur consistently or occurs occasionally in your setup.

It seems to appears when I do an UHPI access, to read the received values.

Rahul Prabhu said:

Is the MCASP setup in TDM mode with 13 time slots ?

MCASP setup is Burst mode

Rahul Prabhu said:

Have you tried to see if the clock polarity is affecting the setup.

yes, there is no change

Rahul Prabhu said:

What is the value of MCASP_RXFMT[2:0] that determines if the data is rotated.

No rotation defined, the value is 0x0

Rahul Prabhu said:

Again, it is unclear why only data[9] and data[10] are shifted. Do have scope shot of this as it appears on the MCASP serializer and how the clock appears when the data appears on the serializer.

After several changes, it seems that the erroneous data are not fixed to the 9th and 10th. I have seen others and it depends on what I'm doing in the interruption 7.


All my registers configuration is in my first post. Here is the code in my interrupt

void Dmax_isr (void)
{
	static unsigned	i;
	static volatile unsigned	*fifo_buffer_ptr;	

	static unsigned last_usecond;
	static unsigned last_timestamp;
	static unsigned first_frame=1;
	
	if(DMAX_FIFO_MCASP0__FMSC_WM_SET)
	{
		last_timestamp = exchange_data[0];
		last_usecond   = exchange_data[1];

		fifo_buffer_ptr=	Dmax_fifo_buffer_mcasp0 + DMAX_FIFO_MCASP0_DESCRIPTOR_READ_POINTER;
				
		for(i=0;i<DMAX_FRAME_SIZE-1;i++)
		{
			exchange_data[i]=fifo_buffer_ptr[i];
		}
			
		if (!first_frame)
		{
			if (last_timestamp == exchange_data[0]) // data 0 is a time counter in second
			{
				if ((exchange_data[1] - last_usecond)!=25) // data 1 is a time counter in usecond, incremented by 25 per frame
					EXCH_CHECK_BOOT_WORD_A = (0xDEAD << 16) + exchange_data[1] - last_usecond;
			}
			else
			{
				if ((exchange_data[1] + 1000000 - last_usecond)!=25)
					EXCH_CHECK_BOOT_WORD_A = (0xDEAD << 16) + exchange_data[1] + 100000 - last_usecond;
			}
		}
		else
			first_frame=0;
			
		for(i=2;i<DMAX_FRAME_SIZE-1;i++)
			if ((exchange_data[i] > 107) || (exchange_data[i] < 95)) // value is always between 95 and 107 decimal
			{
				EXCH_CHECK_BOOT_WORD_B = (i << 16) + exchange_data[i];
			}

		exchange_data[DMAX_FRAME_SIZE-1]=RSTAT_0;
		// when data has been read increment read pointer on fifo descriptor
		DMAX_FIFO_MCASP0_DESCRIPTOR_READ_POINTER += DMAX_FRAME_SIZE;
		if (DMAX_FIFO_MCASP0_DESCRIPTOR_READ_POINTER >= DMAX_FIFO_SIZE)
			DMAX_FIFO_MCASP0_DESCRIPTOR_READ_POINTER -= DMAX_FIFO_SIZE;
			
	}
	DMAX_FIFO_MCASP0__CLEAR_FMSC_WM;
}

Regards,
Aurélien

user5410362 said:

In the interrupt 7 function, I read the 13 last received data from the fifo, but once in a while data[9] or data[10] is 1 bit right rotated.

Can you please provide a specific example of the data you received as well as what you expected? 

My initial reaction to a 1 bit rotation is that the issue must be on the McASP bus itself, e.g. noise registering as an extra clock pulse, etc.  Are some boards more susceptible to this behavior than others?

Hi Brad,

I send 2 counters on the first two 32-bits words then I send eleven 32 bits words with values from 0x61 to 0x6B.
The expected value 0x67 is transformed in 0x80000033 when the error occurs. Value 0x66 becomes 0x33.
Once again, when I read datas directly in the McASP register, the error never occurs. I have the problem only while using Dmax. I have a strong feeling about the error is occurring on the Dmax level. [edit] When I read directly from the McASP register, there isn't any interrupt in the DSP. The RSTAT register is polled in an infinite loop in the main function. Maybe interrupt handling costs a lot of time. [/edit]

I have made some tests and I found a configuration which seems to be error proof.
At first, I used to send the first 32-bits word, then I waited 32 clock cycles before sending the next 32-bits word, then 32 dummy clock cycles, etc...
Now I'm using 64 dummy clock cycles between two words and the error does not occur anymore.

I'm questioning myself about the throughput of the Dmax. I send 2.08MB/s on the McASP. It seems to be OK with 64-dummy bits. But can the Dmax handle burst of 3.12MB/s during 16us (32 dummy bits)?

Also, the error I'm seeing seems to appear when I perform an UHPI read on the DSP. And for now the DSP is empty of any algorithm. I need to ensure that the reception will be OK when the DSP charge will be heavier.

I'm questioning myself about the throughput of the Dmax. I send 2.08MB/s on the McASP. It seems to be OK with 64-dummy bits. But can the Dmax handle burst of 3.12MB/s during 16us (32 dummy bits)?

Also, the error I'm seeing seems to appear when I perform an UHPI read on the DSP. And for now the DSP is empty of any algorithm. I need to ensure that the reception will be OK when the DSP charge will be heavier.