McASP problem with delay in C6748

rahim Soleymanpour

Prodigy 55 points

Hi All,

I am going to play back a voice by LCDK6748. everything is working well with the following code.

while(1) {
input = McASPRxBufRead(SOC_MCASP_0_CTRL_REGS, MCASP_XSER_RX);

delay(500);

McASPTxBufWrite(SOC_MCASP_0_CTRL_REGS, MCASP_XSER_TX,input);

}

but, when I run with delay greater than 800, the code does not play anything. the delay is a symbol of a bunch of procedures. I need the code works with a much greater value of delay.

Can you help me to overcome this problem?

Regards

over 6 years ago

0 Sahin Okur over 6 years ago

TI__Mastermind 27355 points

Hello,

Can you see if any of the flags are set in the RSTAT & XSTAT registers?

Regards,
Sahin

0 rahim Soleymanpour over 6 years ago in reply to Sahin Okur

Prodigy 55 points

Hi Sahin
thank you for your response.
Which kind of flags do you mean?
Regards

0 Sahin Okur over 6 years ago in reply to rahim Soleymanpour

TI__Mastermind 27355 points

Hello,

Refer to section 4.22 & 4.34 of the TRM for the RSTAT & XSTAT register descriptions: www.ti.com/.../spru041j.pdf

For example, if the XSTAT.XUNDRN bit is set it indicates an underrun error has occurred. It would be good to see if this bit is set.

Regards,
Sahin

0 rahim Soleymanpour over 6 years ago in reply to Sahin Okur

Prodigy 55 points

Great.Seemingly, you are right. I need a long delay. How can I solve this problem?

0 Sahin Okur over 6 years ago in reply to rahim Soleymanpour

TI__Mastermind 27355 points

According to the TRM, to recover from an underrun error you need to reset and re-initialize the McASP. To reset the TX side, write a 0 to the XSMRST bit in the GBLCTL register. And then re-initialize the TX side as before. I don't think you will need to reset the RX side.

Regards,
Sahin

0 rahim Soleymanpour over 6 years ago in reply to Sahin Okur

Prodigy 55 points

I do as you mentioned and reset the XSMRST bit, as shown in the following code, but it does not work when I increase dealy as much as 1000
while(1) {
input = McASPRxBufRead(SOC_MCASP_0_CTRL_REGS, MCASP_XSER_RX);

delay(500);
HWREG(SOC_MCASP_0_CTRL_REGS + MCASP_XGBLCTL) &=(0xffff7ffu);
McASPTxBufWrite(SOC_MCASP_0_CTRL_REGS, MCASP_XSER_TX,input);

}

0 Sahin Okur over 6 years ago in reply to rahim Soleymanpour

TI__Mastermind 27355 points

Rahim,

After resetting the XSMRST bit, you still need to follow the initialization sequence described in the TRM, see section 3.1.2. http://www.ti.com/lit/ug/spru041j/spru041j.pdf#page=37

What are you trying to accomplish with the long delay? There could be a better way such as using the EDMA. I recommend taking a look at the C6000 Embedded Design Workshop if you have not done so already which explains real-time processing and the different ways to deal with it.

Regards,

Sahin

0 rahim Soleymanpour over 6 years ago in reply to Sahin Okur

Prodigy 55 points

In fact, the delay is representative of a bunch of complex filters which need a lot of time to complete the process.
In fact, we run our algorithm on LCDK6748 and C6713. we expect the LCDK6748 would have better performance because of this processor' speed and architecture, but the C6713 run our algorithm faster practically. In point of my view, using of EDMA is one of the possible reasons reduces the performance. So I am going to run McASP without interrupt and EDMA. Also, we have no problem when I use McASP and EDMA together.

Thank you for your consideration.
Regards,

Rahim

Processors

Processors forum

McASP problem with delay in C6748