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.

C6000 McASP weird behaviour

McASP works but not as suggested by C6000 workshop labs. I can't understand why?

I have three functions associated to McASP in LCDKc6748. 

fxn: McASP_init()) --> to set up register values of McASP

fxn: McASP_start() to activate serializers and clocks.

fxn: ISR for McASP stereo audio In/out to be called by SYS/BIOS

Case 1:

When McASP_init() and McASP_start() are called before BIOS_start(), there is silence on codec. ISR not called!

Case 2:

If instead of interrupt based program, it is polling based ...XBUFn are serviced during McASP start up as guided by Technical reference manual of C6748..... then it works fine. Polling is achieved by making no changes to initialization sequence but JUST introducing a while(1) loop after call of McASP_start() and before BIOS_start()--> Hence SYS/BIOS never starts.. Inside the while(1) loop, mcasp XSTAT and RSTAT are checked and XBUFn and RBUFn are written accordingly. This works fine.

Case 3:

If the function call to McASP_start() is removed before BIOS_start() and instead it is called as a task with following loop at the end of it.

while(1)
{
//Stay here after McASP_start has activated all clocks and serialisers
}

In this case the ISR is called perfectly fine with no TX/RX underrun or over run. The ISR services the XSTAT[XDATA] when the clocks, frame sync, state machines are activated by McASP_start();

Why is that? Why can't McASP_start() work properly ? please see my project attached.
None of the registers are changed while the calls change.
Please see the main.c code

void main(void) {
	// Key to be written to enable the pin mux registers for write
	sysRegs->KICK0R = 0x83e70b13;
	sysRegs->KICK1R = 0x95A4F1E0;
// Using PINMUX utility, RTS ignored AMUTE is kept
	sysRegs->PINMUX0 = 0x41111111;
	sysRegs->PINMUX1 = 0x10011111;
	sysRegs->PINMUX2 = 0x00000001;
	sysRegs->PINMUX4 = 0x00222200;
// UART SETUP ---------------------------------------------
	UART2Power();		//CPU interrupt #7 for app.cfg
	UART2Default();
// I2C SETUP ----------------------------------------------
        I2C_init(1);		//400K I2C_SCK clock
// McASP SETUP --------------------------------------------
	McASP_init(48000, 16);		// CPU interrupt #5 for app.cfg
// Codec initialise ---------------------------------------
	AIC3106_Init_TTO(48000, 16);	//Fs=48000 and word size = 32 bits
	McASP_start();	//use during polling
	//
//	// =======================polling code=========================================
//	while (1)	// loop forever
//	{
//		if (mcaspRegs->XSTAT & 0x00000020)		// If Tx data ready flag is up
//		{
//			if (mcaspRegs->XSTAT & 0x00000040)	// start of frame
//			{
//				mcaspRegs->XBUF13 = mcaspRegs->RBUF14;
//				mcaspRegs->XSTAT = 0x00000040;
//			}
//			else // if it is last slot of frame
//			{
//				mcaspRegs->XBUF13 = mcaspRegs->RBUF14;
//				mcaspRegs->XSTAT = 0x00000010;
//			}
//			mcaspRegs->XSTAT |= 0x00000020;	// clear XDATA flag
//		}
//	}
	BIOS_start();						// start BIOS Scheduler (never returns)
}

audio_C6000_DMA.rar

  • Dear Sherry,
    We are working on your post.
    Thanks for your patience.
  • I am working on C6000 Optimization code that uses pingPong buffering for stereo audio stream. 

    It has FIRProcess Task. I am keeping it higher priority (2) than McASP_start()... so far nothing.

    I think the right call of McASP would solve the problem for me. 
    Your help will be highly useful and appreciated.

  • Hi,

    Apologies for the late response.

    I would recommend you first  to walkthrough the starterware audio application DMA buffer handling wiki below which is programmed in such a way to work for EDMA ping pong buffer operation.

    The RX paRAM set 0 is initialized to receive the first audio sample in the RX buffer-0 and the paRAM set 0 is linked to linked paRAM set 40.  The paRAM set 40 is linked to paRAM set 41, which is initialized to receive data in RX Buffer 1. The paRAM set 41 is linked back to paRAM set 40 and hence the reception paRAM set is initialized as 0-->40-->41-->40, thereby, the linking does not change as the application executes.

    The EDMA PaRAM set initialization and McASP Tx. and Rx. statemachines are well documented and for basic DMA buffer handling for ping pong operation, please ensure your code is compliant to the below wiki:

    http://processors.wiki.ti.com/index.php/StarterWare_Audio_Application

    To understand more on EDMA ping pong buffer, you could also check the below tutorial:

    http://processors.wiki.ti.com/images/b/b8/Eindhoven_JAN_12-10_IntroTo_Edma.pdf?keyMatch=EDMA

    Thanks & regards,

    Sivaraj K

    -------------------------------------------------------------------------------------------------------

    Please click the Verify Answer button on this post if it answers your question.

    -------------------------------------------------------------------------------------------------------

  • The c6000 optimization workshop does not use DMA, it uses pingpong buffering with normal interrupt handling without involving EDMA3.
    I have got my code working to upto 1024 point FIR filter. It does not go further (may be i need more assembly intrinsics or compiler directives to push processing to its maximum)

    I am continuing to have McASP start-up as a Task instead of pre-BIOS function. Because even though there is no explanation, at least it works. Would look into EDMA next time.

    thank you for looking into this.
  • Hi,

    Thanks for your update.

    May be, you could try EDMA which would be more effective. I am closing your post.

    Thanks & regards,
    Sivaraj K