mcbsp and emda3 new synchronization

Hi Alessandro,

With reference to your previous post, you created a new thread to continue the discussion further. But the link to the previous post is not provided by you.

Probably this might be the link: http://e2e.ti.com/support/dsp/tms320c6000_high_performance_dsps/f/112/t/261992.aspx . Would be helpful if some one who gives / seeks  answer to / from this post.

 

Regards,

Shankari

Hi Alessandro,

Thanks for your post.

I shall provide you the below steps to recognize the unexpected frame sync which is just  a frame sync change as below:

a. Set the XRST bit to 1 to enable the transmitter.

b. Wait for any unexpected frame sync error to occur If the external device provides the bit clock, wait for two CLKR or CLKX cycles. If the McBSP generates the bit clock as a clock master, wait for two CLKG cycles. The unexpected frame sync error (XSYNCERR), if any, occurs within this time period.

Please go through Step 5 in Section 7.1 (Page no. 49) of the link provided below:

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

Also, I suggest you to probe the below signals  through scope at appropriate pins for better debugging to capture unexpected frame sync change

FSX0, FSX1, FSR0, FSR1 @ Pins AJ3, AG4, AH3, AE5 respectively.

But basically, you have to find out the root cause for the external device in restarting the generation of frame and clock sync in some situation and i advice you to resolve this first instead of finding a method to recognize the frame sync change and reinitialize the edma.

 Thanks & regards,

Sivaraj K

 

 

Hi Sivaraj

I've already check SYNCERR of the mcbsp. I generate an HWI when X/RSYNCERR occurs but, in this way, the system can recognize unexpeted Frame Sync only if it's within the 8bit of a slot. If the new frame sync is 8bit aligned but shifted by one slot, the mcbsp doesn't generate the  X/RSYNCERR.

We already know the cause of the external frame sync change. In some situation we have to reset and restart the external FPGA that generate timing for DSP but we can't reset and restart the DSP. In this situation, the fpga generate a new TDM stream with new a frame sync and the offset between the old and the new frame sync is randomic. Is there a method to find out this event in the edma handling?

I try also to generate an HWI from mcbsp on every Frame Sync and check with the CPU the param Cnt value of the edma but the sw is not fast enough.  

Hi Alessandro,

Thanks for your post again.

Basically, Frames are always separated by SRCCIDX and DSTCIDX. For A-synchronized transfers, after the frame is exhausted, the address is updated by adding SRCCIDX/DSTCIDX to the beginning address of the last array in the frame, but for AB-synchronized transfers, after a TR for the frame is submitted, the address update is to add SRCCIDX/DSTCIDX to the beginning address of the beginning array in the frame.

For more details, You shall refer Page No. 26, Section 2.2.1 in TMS320C645x DSP Enhanced DMA (EDMA3) Controller User's Guide link provided below:

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

Also, Please refer Section 3.4 which is Peripheral Servicing EDMA3 Transfer Example for more clarity & understanding.

Thanks & regards,

Sivaraj K

 

hello

I know how the EDMA works with a A syncronized or AB syncronized transfer. I also know how to program the edma to service the mcbsp in a ping-pong configuration.

At the moment my initialization works correctly and the dsp manage a TDM stream of 64 slot, 8 bit word, clock at 2.048MHz.

The data stream, clock and frame sync are generated by a FPGA. In some situation this fpga must be resetted. In this way, the generation of stream, clock and frame sync restart.

The dsp, instead, doesn't receive a reset signal and continues to work. When the fpga restart, the new frame sync has not a delay of 64 slots respect to old frame sync (this delay is randomic). In this situation the emda params are in a uncorrect condition respect to new new frame sync.

Now I'm trying to detect this event with mcbsp or with edma in order to restart my peripherals but with poor results. 

Hi Alessandro,

Thanks for your post again.

There are no other options except generate an interrupt by the mcbsp for every frame sync and EDMA3 channels needs to service continuously McBSP Data for Reload PaRAM Configuration inorder to synchronize between the multi-channel TDM streams and edma internal structure (Acnt, Bcnt and so on)

Step1: You can program to generate receive and transmit CPU interrupts (RINT and XINT) to detect new frame syncronization and even when the serial port is in reset, these signals are synchronized to the CPU clock and then sent to the CPU in the form of RINT and XINT. Please refer Section 4.4.3 in the McBSP Reference guide as given below:

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

Step2: To service the McBSP continuously throughout DSP operation, the channels must be linked to a duplicate PaRAM set in the PaRAM. After all frames have been transferred, it is necessary to implement some form of linking such that the EDMA3 channels continuously reload the necessary parameter sets. The McBSP generates REVT0 for every element received and generates XEVT0 for every element transmitted. Please refer Section 3.4.3.2 in the EDMA controller user's guide as given below:

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

From the above steps, we shall be able to reinitialize the edma parameters with respect to the new frame sync.

Thanks & regards,

Sivaraj K

.

 

Hi Scotto,
I have same issue. Did you find any solution ?

Hi Sivaraj,

As I motioned, I have same issue as what Scotto had.
My observation is, on my older platform (6711), I didn't see this issue.
But on 6746, when McBSP-EDMA combination is working in slave mode, the sequence is lost when I reset the Master processor which is giving FS and clock.
On this board, if I enable FIFO and reconfigure the McBSP-EDMA, then no sequence issues when Master processor reset.
I do not have any additional interrupts as you suggested.

Are you sure,, there is no way to prevent loss-of-sequence issue under these situations without adding the additional monitoring that you suggested.