OMAP3530 MCBSP and DMA configuration problems - DROP error

Mike Turner

I've been reporting problems of one sort or another with both Tx and Rx on MCBSP devices for some time now, via e.g. SR# 1-656366934 SR# 1-659758215 SR# 1-664197881, but I have not been getting any answers for some weeks, and I cannot wait any longer. Apologies if this topic is already covered on here, I've read through approximately 25% of the postings but it's taking too long, so here goes. This problem report represents a crystallisation of a more generic problem that I'm having with MCBSP/DMA config.

I have a signal coming in to MCBSP3 such that CLKX is running at 24MHz and FSX is pulsing high for one clock period in every 48 clocks. The content of DRX consists of 32 bits of data per frame, the remaining 16 bit-times being irrelevant. I am specifying a single-phase frame (RCR2 d15 RPHASE=0).

The DMAs work 100% OK when I define the following :-

    RCR1 d14:8 RFRLEN1           000 0000                       1 word per frame
    RCR1 d7:5   RWDLEN1           101                            32 bits per word
    CSDP d1:0   DATA_TYPE         10                             32 bits per word
    CEN  d23:0 CHANNEL_ELMNT_NBR 0000 0000 0000 0000 0000 0001  1 word per frame

The actual values written to the registers for this successful config are :-
    RCR2 = 00000000
    RCR1 = 000000A0
    CSDP = 00010002
    CEN = 00000001

If I change the definitions to the the following, it fails horribly :-

    RCR1 d14:8 RFRLEN1           000 0001                      2 words per frame
    RCR1 d7:5  RWDLEN1           010                           16 bits per word
    CSDP d1:0  DATA_TYPE         01                            16 bits per word
    CEN  d23:0 CHANNEL_ELMNT_NBR 0000 0000 0000 0000 0000 0010 2 words per frame

The actual values written to the registers for this unsuccessful config are :-
    RCR2 = 00000000
    RCR1 = 00000140
    CSDP = 00010001
    CEN = 00000002

The failure mode is that the first DMA works OK but then there is an error callback partway through the second DMA period, with status 0x0042, which means :-

d6 SYNC=1: Logical channel is servicing a synchronized DMA request

d1 DROP=1: A synchronization collision has been occurred [SPRUF98 wording!]

DMAs then usually cease (though I've been able to provoke continuous repeats of the above behaviour by reducing the speed at CLKX).

Note that there are *NO* other changes in either the software or the input data stream. If I define the data structure to both the MCBSP and the DMA as 1 word of 32 bits, it works. If I define the data structure to both the MCBSP and the DMA as 2 words of 16 bits, it fails.

Please tell me why this is happening and identify the fix - I am completely held up on my deliverable. :-(

Cheers,

Mike

over 14 years ago

0 Mike Turner over 14 years ago

Prodigy 110 points

My apologies for the unreadably small font of my posting - I had trouble with cut/paste.

Should I re-post?

Mike

0 Michael P over 14 years ago

Expert 1810 points

Two important values that I did not see were the values of the DMA4_CCRi and MCBSPLP_THRSH1_REG registers (or MCBSPLP_THRSH2_REG, depending on direction).

For example, I was surprised today to find that the omap_mcbsp_recv_buffer() function in the Linux kernel tree only sets up the DMA to run a single element at a time, without source or destination synchronization -- that is, it will never set the SEL_SRC_DST_SYNC, BS or FS bits in the DMA4_CCRi register -- and this seems to not work well if MCBSPLP_THRSH1_REG is greater than zero. In particular, the DMA stops after the first element. The switch from CEN=1 to CEN=2 would probably trigger this. Might you be seeing the same thing?

(To elaborate, if you want to trigger multi-element DMAs based on larger buffer thresholds, you would probably want to make sure both BS and FS are set in DMA4_CCRi, and set either DMA4_CFSIi or DMA4_CDFIi to match the McBSP's buffer threshold. Which one to set, and whether SEL_SRC_DST_SYNC is set in DMA4_CCRi, would depend on the direction of the transfer.)

0 Mike Turner over 14 years ago in reply to Michael P

Prodigy 110 points

Thanks for the pointers, but the problem is not yet solved.

I have been using a value of 640 in THRSH1 but was setting CSFI to zero. Also I was setting FS in CCR but not BS. Making those two changes, I find unfortunately that the DROP callback now occurs on the very first DMA, and there are no further DMAs.

The register values I have used in that test are :-

RCR2=00000000

RCR1=00000140

THRSH1=00000280

CSFI=00000280

CSDP=00010001

CCR=05044072

CEN=00000002

CFN=00001000

Do you have any other insights? Are there any other register values you'd like me to report?

Cheers,

Mike

0 PaulM over 14 years ago in reply to Mike Turner

TI__Mastermind 27995 points

Mike

I'm not an DMA expert but I have written a simple example which uses DMA to transfer received data into memory using 3 rotating buffers. It's stand alone low level code (no OS) so it's easy to see how the program works. Take a look and see if that helps you with your configuration.

Something I did notice is that your RTHREASHOLD setting does not match the DMA configuration.

From the TRM:

Also, this value (RTHRESHOLD value + 1) indicates the number of words transferred during a receive data DMA request, if receive DMA is enabled

I understand this to mean that RTHESHOLD +1 = CEN

If that does not help, can you provide me with the complete DMA and MCBSP configurations?

Paul

MCBSP_RX_DMA_1.zip http://e2e.ti.com/cfs-file.ashx/__key/CommunityServer.Components.PostAttachments/00.00.18.63.17/MCBSP_5F00_RX_5F00_DMA_5F00_1.zip

0 Mike Turner over 14 years ago in reply to PaulM

Prodigy 110 points

Paul,

Many thanks, I think you've hit it on the head!

I had misinterpreted that section of the manual, I was thinking that "DMA request" is the same as "DMA transfer". As I'm using block-level transfers of up to 32768 frames, I assumed this text could not apply to my config, else the block size would have to be constrained way below the defined limits of CFN. Clearly there are many DMA requests within a complete DMA transfer, in the true view.

There is also a collision with another misreading. I've been using 640 as an arbitrary THRSH1 because that was half the FIFO (and I didn't see it as being tied to CEN) - but that FIFO size of 1280 applies only to MCBSP2 as the very next sentence points out. The other MCBSPs have less bits, though SPRUF98 as usual throws a bit of a googly at us with "For other McBSPs, RTHRESHOLD is an 8-bit field (bits 7 to 10 are reserved). In other words, the other McBSPs are limited to a FIFO width of 0x7F." I think we'll take it to be a 7-bit field, then!

The value 640 doesn't set any of bits 0-6, so I have been using a THRSH1 of effectively 0 (meaning an actual threshold of 1). So the transfers with elements-per-frame counts of 1 are working, but any other count is failing.

I will now verify this experimentally and post again shortly.

Cheers,

Mike

0 Mike Turner over 14 years ago in reply to Mike Turner

Prodigy 110 points

Yup, that's solved the problem for *all* my configurations, I believe.

Many thanks again, Paul.

0 PaulM over 14 years ago in reply to Mike Turner

TI__Mastermind 27995 points

Mike

That's great! I'm glad I could help.

If you could mark the answer as verified it helps "compete" the thread.

Paul

Processors

Processors forum

OMAP3530 MCBSP and DMA configuration problems - DROP error