Unable to configure McBSP FIFO depth

KrzysztofCh

thHi All,

I've encountered following issue:

McBSP is handled by DMA, HW FIFO for RX and TX is enabled because if disabled some samples were lost (there is only 2,5us to handle each sample and that's not enough when L138 is loaded). I'm using TI EDMA3 driver but our own McBSP driver.

McBSP FIFO in TX path can be controlled by WFIFOCTL register. It seems (it's not explicitly written) that field WNUMEVT controls the depth of the FIFO by defining event trigger condition. I've followed PSP example and said WNUMEVT to 1 although it was a bit strange to see that in PSP WNUMEVT is set to the value which is not defined in CSL

Mcbsp.c:

/* configure the transmit channel                                 */
/* Step 1 : configure the "WNUMDMA" and "WNUMEVT" bits before     *
* enabling the FIFO                                              */
hMcbsp->fifoRegs->WFIFOCTL = (1 << CSL_BFIFO_WFIFOCTL_WNUMEVT_SHIFT);

cslr_mcbsp.h

#define CSL_BFIFO_WFIFOCTL_WNUMEVT_0WORDS   (0x00000000u)
#define CSL_BFIFO_WFIFOCTL_WNUMEVT_4WORDS   (0x00000004u)
#define CSL_BFIFO_WFIFOCTL_WNUMEVT_8WORDS   (0x00000008u)
#define CSL_BFIFO_WFIFOCTL_WNUMEVT_12WORDS (0x0000000cu)
#define CSL_BFIFO_WFIFOCTL_WNUMEVT_16WORDS (0x00000010u)

Setting WNUMEVT=1 gives 64 words depth of FIFO. If I've tried to change WNUMEVT to different value McBSP is no longer triggering any events to DMA. I've tried to manipulate second WFIFO parameter WNUMDMA but I also didn't helped. It seems to me that the only acceptable configuration is WNUMEVT=1.

Am I doing something wrong or is it known/unknown HW issue?

For me, 64 words depth is much to deep since I want to update tx buffer on the fly. With such FIFO tx buffer updates are shifted out from McBSP 64 samples later - not acceptable latency.

Thanks in advance for any clue.

over 15 years ago

0 Mukul Bhatnagar over 15 years ago

TI__Guru* 83705 points

Hi Krszysztof

KrzysztofCh said:
McBSP is handled by DMA, HW FIFO for RX and TX is enabled because if disabled some samples were lost (there is only 2,5us to handle each sample and that's not enough when L138 is loaded). I'm using TI EDMA3 driver but our own McBSP driver.

Are you completely sure that no system level optimization will help your use case without the FIFO enabled? Please let me know if you have already tried or eliminated possible optimizations like

1) Keeping the McBSP buffers in on chip memory (L2 or Shared RAM). This might typically not be possible if internal memory is being used to configured as cache or used for more critical data/program sections

2) Try to keep McBSP transfers on an EDMA3 Queue , exclusively and surely not put long/bulk transfers on the same EDMA CC queue. To eliminate the chances of McBSP RX/TX events being stuck behind a big paging type transfer in the EDMA3 CC queue.

3) If there are multiple masters in play (like DSP, ARM , EDMA3 TC controllers , USB etc) , you should ensure that the Queue-TC servicing the McBSP is kept at the highest priority (priority 0) as compared to rest of the masters. This is controlled by the Master Priority register

4) If the McBSP buffers are in mDDR/DDR2 memory, please also make sure that the PBBR register in the mDDR controller (Offset 0x20) is set to a value lower then default (0XFF), typically a 0x20 value serves well.

Above are few recommendations that should be tried irrespective of FIFO enabled/disabled. Typically 3/4 are easily managed and done. 1/2 might be system dependent.

Going back to your FIFO specific queries.

KrzysztofCh said:
McBSP FIFO in TX path can be controlled by WFIFOCTL register. It seems (it's not explicitly written) that field WNUMEVT controls the depth of the FIFO by defining event trigger condition. I've followed PSP example and said WNUMEVT to 1 although it was a bit strange to see that in PSP WNUMEVT is set to the value which is not defined in CSL

The WNUMEVT/RNUMEVT control the trigger threshold. The FIFO size for RX and TX is always 256 words/ 64 words. I believe it was not defined just to keep the CSL macro/enumeration simple rather then having 1 to 64 words definitions. It is true though that the PSP example for McBSP only seems to make use of FIFO threshold of 1 alone (keeping this configurable has more implications on the EDMA settings, as this would need to change with every WNUMEVT setting)

KrzysztofCh said:
Setting WNUMEVT=1 gives 64 words depth of FIFO. If I've tried to change WNUMEVT to different value McBSP is no longer triggering any events to DMA. I've tried to manipulate second WFIFO parameter WNUMDMA but I also didn't helped. It seems to me that the only acceptable configuration is WNUMEVT=1.

Setting WNUMEVT =1 should make the McBSP trigger a DMA event every 1 word , not 64 words, let me know if you think this is not happening? If you change the WNUMEVT value then you would need to change the EDMA driver to make sure that the ACNT x BCNT is equal to the number of words/bytes expected every trigger event. WNUMDMA needs to always be set to 1 for McBSP (it changes for McASP).

Please see if any of these suggestions help and/or if you have follow up questions on this.

Regards

Mukul

0 KrzysztofCh over 15 years ago in reply to Mukul Bhatnagar

Prodigy 140 points

Hi Mukul,

thanks for your reply. I will try some optimization but I'm afraid that it might be not enough to ensure that DMA will always handle McBSP on time. Aspecially, that McBSP doesn't have any mechanism to catch underrun situation and in slotted transmission underrun error kills whole packet because it shifts slots (if you have 4 slots per frame - A,B,C,D, overrun will shift A to B, B to C,...)

But I still don't understand the intention of WNUMEVT because in it's definition it's said that:

When the Write FIFO has space for at least WNUMEVT words of data, then an XEVT (transmit DMA event) is generated to the host/DMA controller.

Let me explain how I understand it:

- let say that WNUMEVT = 20 and WNUMDMA = 1 then FIFO will generate DMA event only if there is a space for at least 20 words and this event will cause 1 word copy action.

- we enable FIFO (but peripheral is still disabled) so it's empty and it has 256 words of free space so it generates dma event because 256 is bigger than 20. DMA handles event and there is 255 words of free space in FIFO. This will continue untill there is 19 words of free space. Then there is no more events from FIFO because event is generated if "Write FIFO has space for at least WNUMEVT words of data" (quotation from McBSP datasheet).

- we enable McBSP it takes one sample from FIFO so there is 20 words of free space -> FIFO generates DMA event. Then there is 19 so there is no event.

So from WNUMEVT definition it shall controll FIFO depth. If not then the definition of WNUMEVT is unclear for user (me).

Regards,

Krzysztof

0 Mukul Bhatnagar over 15 years ago in reply to KrzysztofCh

TI__Guru* 83705 points

Hi Krzysztof

I understand the confusion caused by the documentation and I think it needs to be clarified better in the user guide.

Bottom-line , still as explained in my previous post , is that if you change the WNUMEVT value to anything more then 1, you would need to ensure that the EDMA ACNT/BCNT is such that number of bytes transfers per EDMA sync event is equal to the WNUMEVT value (WNUMDMA is always 1 for McBSP).

After talking to PSP and IP experts, I have tried to summarize the explanation below, please see if it helps (the "reason" section has the crux of what is likely confusing in the definition of WNUMEVT)

-----

McBSP has FIFO of 64 words each capable of holding a 32 bit wide data.

Scenario 1

The Mcbsp is configured to use the FIFO and the slot width is configured as 8 bit with no of slots is configured as 1.The McBSP is using only the single frame.

The Mcbsp is placed in reset.
The FIFO is enabled and the TX FIFO threshold (WNUMEVT) is programmed as 32.
- i.e. An event is generated by the FIFO whenever it has at least thirty two empty words in the TX FIFO.
The EDMA is programmed to transfer 1 (slot size 8 Bit) * 32 (threshold ) bytes of data per sync event from the FIFO.
The IO packet is programmed in to the EDMA paramset and the EDMA transfer is enabled.
As soon as the EDMA is enabled, the FIFO generates 2 events (one for each of the 32 words).
- When the first event is received from the FIFO the EDMA transfer 32 bytes(1 (slot size 8 Bit) * 32 (threshold )) and
- Similarly for the next event and the FIFO gets completed filled up.
As soon as the McBSP is brought out of reset and the frame sync and bit clock is enabled the transmission of the data from the FIFO to McBSP happens.
Whenever a space for 32 EMPTY words is available in the FIFO, the FIFO generates an event to the EDMA which in turn transfers a 32 bytes of data to the FIFO.

Scenario 2

The Mcbsp is configured to use the FIFO and the slot width is configured as 8 bit with no of slots is configured as 1.The McBSP is using only the single frame.

The Mcbsp is placed in reset.
The FIFO is enabled and the TX FIFO threshold (WNUMEVT) is programmed as 32.
- i.e. An event is generated by the FIFO whenever it has at least 32 empty words in the TX FIFO.
- FIFO should continue to generate transmit events to EDMA till the empty words become 31
- That means we should get 33 events in total.
The EDMA is programmed to transfer 1 (slot size 8 Bit) * 1 (only One) bytes of data per sync event from the FIFO.
The IO packet is programmed in to the EDMA paramset and the EDMA transfer is enabled.
As soon as the EDMA is enabled, the FIFO generates first an event to the EDMA.
On reception of this event, the EDMA transfers 1 Byte (1 (slot size 8 Bit) * 1 (only One)) of data.
After this there are no SYNC/ Transmit events from the FIFO to EDMA

Because no more events are generated by the FIFO the TX section does not transmit any more data and the EDMA paramset also remains same.

Observation

In scenario 2, since the FIFO has still 63 EMPTY word and the FIFO is configured for a threshold of 32 it is expected (based on user-guide definition) that the FIFO generates events until only 31 empty words are available in the FIFO. But after the first event the FIFO does not seem to send any more events to the EDMA

Reason

From FIFO specification:

If the write FIFO has space to accept at least WNUMEVT 32-bit words, it generates a Tx DMA request to the host. It then waits for a response from the host. Once WNUMEVT words have been written to the FIFO, it checks again to see if there is space for WNUMEVT 32-bit words. If there is space, it generates another Tx DMA request to the host, and so on. In this fashion, the write FIFO will attempt to stay filled. So in Scenario 2 unless the EDMA sends 32 bytes on the TX DMA request, FIFO will not generate another TX event till WNUMEVT words are written.

So general recommendation for TX FIFO settings

For TX operation, the FIFO reaches a depth of DEPTH-WNUMEVT before a new event is scheduled. Having WNUMEVT smaller we are keeping the FIFO “fuller”. By setting WNUMEVT larger we allow the FIFO to become “emptier” and thus closer to real time deadline violation. A compromise may be to set WNUM_EVT = DEPTH/8 or DEPTH/4 or something like that

WNUMEVT = small -> better for real time, worse for edma burst efficiency

WNUMEVT = large -> worse for real time, better for edma burst efficiency

---

I hope this helps. Let me know if you have additional questions.

Regards

Mukul

0 SGQ over 11 years ago in reply to Mukul Bhatnagar

Expert 2875 points

Hi Mukul,

I am having problem with EDMA3/McBSP(with FIFO enable) doing 32 channel(TDM) for 32 bit words transfer. My code works with 8 channels.

Reading from your post: "If you change the WNUMEVT value then you would need to change the EDMA driver to make sure that the ACNT x BCNT is equal to the number of words/bytes expected every trigger event." For 32 channels of 32 bits (4 bytes), I would need to set WNUMEVT = 128 (32 X 4). But McBSP FIFO is only 64 deep.

I have been working on this issue in E2E here:

http://e2e.ti.com/support/dsp/c6000_multi-core_dsps/f/639/p/312470/1158330.aspx#1158330

What can we do?

Thank you.

Regards,

Steve

Processors

Processors forum

Unable to configure McBSP FIFO depth

Observation

Reason