McBSP example in C6657

Hi Steven,

You have been supporing me on my McBSP and EDAM3 implementation.  I have been running McBSP with 8 TMD configuration.  It has been working well.

Now we increase McBSP port to 32 TDMs with 4 x clock rate, 49.152MHz.  When I run the code, transmit side is working correctly.  But receive side data slips.  For example, I expect to receive 32 samples for channel 0, 1, 2, ... 31.  I would see 32 samples for channel 0, then only 16 samples for channel 1, then 0 samples for channel 2, then 7 samples for channel 3, etc.

For my EDMA3 and McBSP transmit and receive are configured identically.  What might be the cause of receive problem?

Thank you.

Regards,

Steve Qu

Steve,

It looks like you increase both channel number and clock rate. Are you able to narrow down the issue to see if it is related to channel number (EDMA setup) only or clock rate only please?

If it is related to clock rate and you were using external clock source before, are you able to switch to internal clock source and see if the issue occurs as well?

I am not sure if you could change the clock rate on the external device which connected to McBSP to match with internal clock rate from C665x. But if it is doable, it could another check point for you to narrow down the issue.

Hi Steven,

I cannot change the clock rate easily, as you mentioned.  For the record, I use AB Synchronized transfer and through McBSP FIFO.

I reduced channel to 8 with same clock rate.  The receive errors are still there, no transmit errors as before.

Do you have an example of EDMA3 with McBSP running 49.152MHz, 32 TDM channels?

I know that McBSP's maximum clock rate is 50MHz.  We are running almost at maximum.

Thank you.

Regards,

Steve

Steve,

I do not think the EDMA setup will be different for any specific clock rate.

Your experiments seem to indicate the issue is due to the clock rate. Please double check the clock source of data clock (CLKX/CLKR) and frame sync clock (FSX/FSR). Section 2.12 in McBSP user guide has one table for the combination of clock source selection. Please follow the initialization steps and make sure you have the correct setup especially for data clock/frame sync input.

Section 2.12.2 also mentions one special case when external device is the transmit frame master. It will affect transmit side which may not be your case. But it could be worth to take a look in case you see anything unusual on transmit side as well.

Hi Steven,

Our CLKX and CLKR are derived from a single source, and FSX and FSR also from single source.  Both are locked!

Have you tried  EDMA3 with McBSP which is running 32 TDMs at abour 50MHz?

Attached is the memory display of part buffer of EDMA3 receive buffer.  We feed all 32 TDMs (channels) with channel identification 0x00 to 0x1F.  Please note the missing data.

Thank you.

Regards,

Steve

Steve,

I think McBSP module has been verified working with internal data clock and internal frame sync clock around 50MHz and 128 channels. But I do not have the code and platform to verify now. 

If you would like, please share your McBSP/EDMA configuration code here that all the TIers and community members could help with reviewing to see if anything is missing in the code first. Thanks.

Hi Steven,

We are using external clock and frame sync.  But I tried using internal and the results are the same.  At this time, I am running out of things to try. 

Our company policy doesn't allow me to post code.  This code is pretty much the ones you send me.  I can send you the code directly to your email for your review. 

Thank you.

Regards,

Steve

Hi Steven,

I am attaching the memory dump for McBSP/EDMA3 receive buffer.  Our test hardware send contents as channel  number, such as value 0 in channel 0, value 1 in channel 1, ... value 0x1F in channel 31.  This receive buffer is EDMA sort output.  It should be two rows (32 values) for each channel.

As you can see, 0x13, 0x14 and 0x16 and 0x17 are correct, missing 0x15.   McBSP stream comes in as 0, 1, 2, ... 31, 0, 1, 2, 3, ... continuously.  How could it miss 0x15 for every frame?    It seems like EDMA3 problem.  What could it be wrong?

Thanks.

Regards,

Steve

Hi Steven,

Have not heard from you for a while.  Hope you are still working on my EDMA3/McBSP issue.

After more testing, I discover that using L2 and MSMC memory make big difference.  When using L2, receive buffer show lose complete 32 bit values and corrupted values.  But when using MSMC, receive buffer only show corrupted value, no lose of complete 32 bit values.

What is the operational difference for EDMA3 to access L2 and MSMC?

Thank you.

Regards,

Steve

Steve,

Sorry that I could not get back to you sooner. It might be better to start a new thread for different issue next time, that all the other community members could be notified and try to help as well.

The only major difference I can think of between L2 and MSMC SRAM is the cache configuration. I am not sure how the data flow is in your setup but if only EDMA receives from McBSP to device memory (the CPU does not touch the receiving data), then it should not matter it is L2 or MSMC. But you can still disable all the L1D and L2 cache in the beginning of your test to see if it matters.

For the data corruption, I am thinking it could be related to the clock/frame sync clock setup. Could you confirm the clock setup in your McBSP registers configuration and compare with McBSP user guide to see if they make sense please?

For your convenience, I list some bit fields below to check but it will be better to check all the other related ones in user guide as well:

(if you use external source for both data clock and frame sync clock)

DLB = 0 in SPCR (no loopback)

FSXM = FSRM = 0 in PCR (external source)

CLKXM = CLKRM = 0 in PCR (external source)

section 2.5.5.5 "In the case of a 0-bit data delay, the data must be ready for reception and/or transmission on the same serial clock cycle. For reception, this problem is solved by receive data being sampled on the first falling edge of CLKR when an active (high) FSR is detected"

RDATDLY = 0 in RCR (0-bit delay)

CLKRP = FSRP = 0 in PCR (falling edge, active high for receive)

Please also check the frame length and word length to match your receiving stream as well.

Hi Steven,

We found our problem on McBSP 32 channel.  Now on C6657 McBSP 32 channels and about 50MHz, external clock and frame sync works.

Thank you very much for the support.

Regards,

Steve