McBSP - RFULL error

Which DSP are you using?

How fast is the McBSP clock running?

What driver software are you using, or did you write your own software to service the McBSP interrupt?

How much data do you read successfully before the RFULL flag is indicated?

Regards,
RandyP

Hi Fjs,

Thanks for your post.

I assume that, you are using C6748 DSP since you have not mentioned the series of DSP processor.

Actually RFULL=1 in the serial port control reigster (SPCR) indicates that the receiver has experienced overrun error condition and this conditions is set when the following are met:

• DRR (Receive Data register) has not been read since the last RBR-to-DRR transfer.

• RBR (Receive buffer register) is full and an RBR-to-DRR  copy has not occured

• RSR (Receive shift register) is full and an RSR-to-RBR transfer has not occured

The above cause occur only if DRR has not been read by the CPU or the EDMA controller since the last RBR-to-DRR transfer (RRDY= 1), an RBR-to-DRR copy does not take place until RRDY = 0. This prevents an RSR-to-RBR copy. New data arriving on the DR pin is shifted into RSR, and the previous contents of RSR are lost. Because of this data loss of previous contents, RFULL=1 is set in SPCR and this triggers the overrun error condition.

Please refer Section 24.2.7.5.1 in the C6748 TRM as below for more details on RFULL error condition and how to clear the RFULL bit:

http://www.ti.com/lit/ug/spruh79a/spruh79a.pdf

Thanks & regards,

Sivaraj K

Hi Randy, Hi Sivaraj,

thanks for your answers!

Yes, i use the C6748 DSP which is build in the OMAP-L138. The CLKS has a frequency of 12MHz and the CLKR a frequency of 3MHz. The MxBSP is programmed as slave and all clocks (CLKS, CLKR and FSR) are provided by the I2S device.

Sivaraj, i read the section about the RFULL error in the description of the McBSP, but the Receive interrupt has the highest interrupt and the conditions could never occures.

I don't use a driver software. I write the init function by myself. The RFULL error occures differently, Sometimes it works for hours and sometimes it occures immediately, but never before the third or fourth sample (i think, this results from the structure of the McBSP unit).

Fjs,

The easiest solution would be to try an example program offered as part of the software delivered with your board, if it is a TI LCDK or such board. Or you can download software from the Wiki.

The harder solution will be to study very hard on the TRM and make sure you are following every step that is description for initialization and operation of the McBSP port. You will then need to look at the pins with a scope or logic analyzer to see if they are behaving the way you expect them to.

Fjs said:

i read the section about the RFULL error in the description of the McBSP, but the Receive interrupt has the highest interrupt and the conditions could never occures.

Please explain this a little more. It is not clear to me what you are saying exactly. In particular, I am not sure what "the conditions could never occur" means.

Regards,
RandyP

Hi Randy,

thanks for your answer!

Initializing the McBSP and setting up the interrupt system is only a few lines of code, so it should work without a software driver. The McBSP initialization process is done as described in Chapter 7.1 of the McBSP reference guide.

In the meantime i examined the problem a little bit more. I think it is a problem with the interrupt system. The McBSP uses the interrupt HWI_INT6. If the error occures, i got the following values from the core registers:

CSR = 0x14000103 // GIE enabled
IER = 0x000080F3 // INT 6 enabled
IFR = 0x 00004000 // Int-Flag 6 not set

Additionally i read the McBSP register:

MCBSP1->SPCR = 0x4007; // RRDY and RFULL flag set

Because of the missing interrupt flag, the interrupt service routine is not called and the data in the DRR register is not read out. So the RFULL error occures.

But why is sometimes the interrupt flag not set, although the RRDY flag is set? What is the reason for this behaviour?

Fjs,

If you try our sample code that has already been debugged, and it works, then you will have some working code to compare your code with.

Your data rate is fairly slow but your interrupt results still imply that an interrupt is getting missed. If RRDY goes high again after causing an interrupt but before RRDY gets cleared, or maybe some other interrupt flagging race condition, then the IFR flag might not get set since it would not see an edge on the flag from the McBSP.

This is very difficult to debug without doing full system analysis, including all interrupt latencies and code latencies, delays in this ISR, compiler settings, etc. That is work for you to do. To get the best answers from us, you should try sample code, if any is available.

Make sure you are setup to get an error interrupt when RFULL is set so you can note it and perhaps repair it.

Try not using the ISR, but instead poll RRDY to read the data and then see if you can get it to work better. This will help point to the cause.

Regards,
RandyP

Hi Randy,

thanks for your answer!

From your answer i see, that i did not explain the RFULL situation enough.

If the RFULL error occures, it is not a single event. It occures permanently. I have a routine which reinitialize the McBSP unit and i see that in this case the interrupt occures exactly two times and then the RFULL error occures again.

In the meantime i tested a little bit more. Restarting the linux application with a restart of the audio DSP programm does not eliminate the problem. I reset the I2S device (radio device), but the error occures again.

Rebooting the whole linux system on the microcontroller solves the problem.

I checked the McBSP and the corresponding PINMUX registers in the error case, because the linux system could have access on it. But everything is fine.

Do you have any idea what i can additonally check?

Hi Randy,

in another post ("C6747 DSP misses EDMA3 TC Interrupt occasionally") i found a sentence from you:

"What I mean is that some hardware issues could occur where interrupt flag bits or status bits could miss being cleared, but that would usually lead to a complete failure to receive more interrupts. In your case, the interrupts continue so the hardware system is healthy as implemented in your application."

Maybe this could be the reason for our behaviour, because during a reboot of the linux system a complete hardware reset will be done. Could you explain a little bit more what hardware issues do you mean?

Where are you running Linux that affects the C6748? I assume you are not running Linux on the C6748, so this leaves me confused.

Please find an example program and try to get the serial port working with that. If it does not work and you get the RFULL in that case, It will be easier to get some discussion going about code problems. If it does work, then you have an example to compare against the custom code you have written yourself.

Sivaraj may have some suggestions for drivers and examples. I do not.

Regards,
RandyP

Hello RandyP,

Fjs and me are working on the same project, so i am joining this thread.

Linux is running on the ARM. The McBSP is under control of the DSP application.
And this seems to be a McBSP hardware issue. In this error state resetting the
McBSP and setting all the configuration from the beginning does not help -
the same situation is happening again.
Only a reset of the whole system works.

This error can occur on another code basis, too. Please see the following
thread:   

OMAP L138 McBSP - Strange Behaviour
http://e2e.ti.com/support/dsp/omap_applications_processors/f/42/t/239731.aspx

Any informations about how to prevent this state and how to reset the McBSP in
software are very helpful!

Regards,

Bastian.

Bastian,

Thank you for joining this thread. Your help will be appreciated.

As I explained above, the difficult way to solve this problem is to analyze every element of the application and find the correction to the code that will make this work. There is no easy wisdom that can be shared to tell you remotely which register to change or which thread is blocking your transfers. The best I can do for that path is to recommend more study of the McBSP User Guide to understand the sequences to initialize and to restart the McBSP. For example, in the User Guide it says

McBSP UG: said:

Either of the following events clears the RFULL bit to 0 and allows subsequent transfers to be read properly:
- Reading DRR
- Resetting the receiver (RRST = 0) or the device

The easy wisdom to find a solution is to find an example program and try to get the serial port working with that. If it does not work and you get the RFULL in that case, It will be easier to get some discussion going about code problems. If it does work, then you have an example to compare against the custom code you have written yourself.

Another path I have used is to start disabling everything in your application, either by removing the code or disabling interrupts and such. Get the application reduced to where it is only a McBSP transfer application and see if it still fails. It will be much easier to determine if you have timing issues blocking the McBSP accesses or logic errors in the registers being used. But at your speeds, the DSP should be able to easily keep up with the McBSP data rate even using polling instead of interrupts or EDMA.

Regards,
RandyP