We cannot synchronized the Tx data for McBSP in C6748

Hi sinan,

Here what i suspect is bit clock and frame synchronization is lacking.
Please check
www.ti.com/.../spruh79a.pdf (C6748 Technical Reference manual)
 
 
For transmission, the transmit clock polarity bit, CLKXP, sets the edge used to shift and clock out transmit data. Data is always transmitted on the rising edge of CLKX_int. If CLKXP = 1 and external clocking is selected (CLKXM = 0 and CLKX is an input), the external falling-edge-triggered input clock on CLKX is inverted to a rising-edge-triggered clock before being sent to the transmitter.

When FSX(Transmit frame sync pulses) is output driven by the sample rate generator, they are generated (transition to their active state) on the rising edge of the internal clock, CLKX_int.
 

Hi Sinan,

We regret for your inconvenience..

I have few questions from your end to address,

1.  Have you set the error flag XSYNCERR bit in SPCR to ensure that it was a unexpected frame sync which is not synchronized with bit clock? If so, any tx. interrupt is generated (XINTM in SPCR) due to XSYNCERR? If no, writing a 1 to XSYNCERR would set the error condition when the transmitter is enabled (XRST = 1).

Usually, A transmit frame sync error will occur for the first time when the transmitter is enabled (XRST = 1) after a device reset. In order to overcome this, after enabling the transmitter for the first time, please do ensure the following:

1. Wait for two CLKG cycles. The unexpected frame sync error (XSYNCERR), if any, occurs within this time period.

2. Disable the transmitter (XRST = 0). This clears any XSYNCERR.

3. Re-enable the transmitter (XRST = 1).

I have reviewed your attached code and I understand from that you have configured for FrameSync ignore and obviously, your XFIG in XCR should be 1 and the unexpected framesync can be ignored and if you do not want to ignore the frame sync, kindly configure it for XFIG = 0 in XCR, sothat, the unexpected FSX pulse will abort the ongoing transmission and would set the XSYNCERR bit in SPCR to 1, and reinitiates transmission. In your case, since it is configured as Mcbsp_FrmSync_IGNORE (enum variable in mcbspChanConfig), then th e framesync which is not synchronized with the bit clock would not impact the ongoing transmission and will not abort. This is my understanding, kindly confirm whether your data transmission aborts?

Please evaluate the status of XFIG in XCR, XSYNCERR in SPCR with the above context.

In my opinion, even the unexpected framesync in your case which is not synchronized with your bit clock should not impact the ongoing transmission since you configured it as  Mcbsp_FrmSync_IGNORE in mcbspChanConfig structure which would not abort the transmission. If you would like to synchronize the framesync with bitclock, please configure it as XFIG to 0, sothat, which will not ignore the unexpected framesync and discard the ongoing transmission & it would reinitiate transmission. For more details on this, please refer sections 24.2.7.4.1 & 24.2.7.5.5 (see Case1 which is your configuration FSX ignore) from the TRM below:

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

In this case, unexpected FSX pulses can be ignored, and the transmission would continue smoothly and other configuration of your code holds good.

If possible, please give us the register dump of SPCR, XCR to ensure the above.

Thanks & regards,

Sivaraj K

-------------------------------------------------------------------------------------------------------

Please click the Verify Answer button on this post if it answers your question.

-------------------------------------------------------------------------------------------------------

Hi,

Hi,

Thanks for your update.

Is your data transmission aborts with case "Mcbsp_FrmSync_DETECT", if so, whether it re- attempts to reinitiate transmission or not?

Based on your register screenshot, there is no interrupt generated due to XSYNCERR when the transmitter is enabled. Is my understanding correct?

Can you confirm, after 2 to 3 CLKG cycles, whether the framesync synchronizes with the bit clock? I mean, whether it happens on the first time or it happens continuously even after 2 to 3 CLKG cycles, kindly confirm.

Thanks & regards,

Sivaraj K

-------------------------------------------------------------------------------------------------------

Please click the Verify Answer button on this post if it answers your question

-------------------------------------------------------------------------------------------------------

Hi,

The XSYNCERR bit is zero. That means no interrupt was ever generated if the only way to clear this bit is to reset the transmitter. So how can you say "Is my understanding correct?". It is what it is. Why do we go in circles?

What happens if  framesync synchronizes on the first cycle or 2nd or 3rd. Where will this lead us?

As I have mentioned in my previous message we have used internal signaling. So internally it must synchronize anyway.

Even if we internally genenarate the signals how come we cannot have a stable output?

I need direct honest answers.

project link  telsam.com.tr/ti/mst_mcbsp_test3.zip

 Attached is the code of ours.

Hello Anthony,

We will go step by step so we would only answer to case "a".

We ran the mcbsp Master project.

We took 4 pictures of the signals on the scope. Below are the links to those pictures.

1. This picture below is the frame and clock when the scope is paused at an arbitrary time.

http://i.hizliresim.com/5dmz8L.jpg

2. This picture below is the frame and clock when the scope is running.

http://i.hizliresim.com/MEg4WM.jpg

My question here is when the scope is running why can't I see stable signals as those where the scope was paused.

3. This picture below is the frame and data transmitted when the scope is paused at an arbitrary time.

http://i.hizliresim.com/8g2o21.jpg

My question regarding this picture is although the value of the buffer to be transmitted is the same why is the data transmitted different at each frame?

4. This picture below is the frame and data transmitted when the scope is running.

http://i.hizliresim.com/7kXZgl.jpg

Again no stable signals on run-time.

Regards

sinan lezgioglu said:

1. This picture below is the frame and clock when the scope is paused at an arbitrary time.
i.hizliresim.com/5dmz8L.jpg
2. This picture below is the frame and clock when the scope is running.
i.hizliresim.com/MEg4WM.jpg
My question here is when the scope is running why can't I see stable signals as those where the scope was paused.

Do you use the trigger function of the oscilloscope? On what signal is the oscilloscope triggering?

sinan lezgioglu said:

3. This picture below is the frame and data transmitted when the scope is paused at an arbitrary time.
i.hizliresim.com/8g2o21.jpg
My question regarding this picture is although the value of the buffer to be transmitted is the same why is the data transmitted different at each frame?

sinan lezgioglu said:

4. This picture below is the frame and data transmitted when the scope is running.
i.hizliresim.com/7kXZgl.jpg
Again no stable signals on run-time.

Again do you use the trigger function of the oscilloscope? On what signal is the oscilloscope triggering?

Hi,

Yes, the trigger level was not correct. Very sorry for the inconvenience. Struggling at the same level for a long time distracted us. We started to make simple mistakes.

Now with the trigger level corrected, and "signal 1" (That is the frame signal) on the scope screen is triggered, we observe stable frame and clock signals.

We made some changes in the example (pdk_C6748_2_0_0_0\biospsp_03_00_01\drivers\examples\evm6748\mcbsp\Master)

1. At line 303 of mcbspSampleMaster_io.c we made buf[] content constant. Set to a value 0x80.

2. At line 199 we have changed the "for" loop to a infinite "while" loop: 

while (1)       //  for (count = 0; count < LOOP_COUNT; count++)

3. We have removed the line 215:

//Task_sleep(100);

With these changes we observed the frame and data on the scope with the frame signal triggered (Signal 1 on the scope).

With the data signal (signal2) set to a constant value of 0x80 we must now observe a stable data output on the scope.

Instead what we observe is as on the video in the following link:

drive.google.com/.../view

sinan lezgioglu said:

With the data signal (signal2) set to a constant value of 0x80 we must now observe a stable data output on the scope.

Instead what we observe is as on the video in the following link:

drive.google.com/.../view

a) Yes I think you should observe a stable signal. From the video it seems that FS is stable.

b) Can there be a conflict at the pin level? Can it be that an other device drives the McBSP DX pin?

The example is configured fro McBSP1. McBSP1 pins are used as boot pins too.
or are you using MCBSP0?

It does not seem that the McBSP pins are available on the expansion connector. Where do you measure the signal? How did you connect it to the other board originally?
What is the pinmux options for the MCBSP you use? (see PINMUX reg in SYSCFG module).
What is the pull up/pull down option configured for the pins used? (see MCBSP1 pins are part of CP[2] group).
Are there external pull up/down on the signal you use?

A.

Yes, the McBSP1 pins (DX1, DR1, FSX1, FSR1) are used as boot pins.

We are not using McBSP0.

The McBSP1 pins CLKR1 and CLKX1 are used by U22. We have removed U22 from the board (U22 is STEREO AUDIO CODEC. We don't use it).

Eventually, all the pins are cabled out from the board since they are not available on the expansion connector. But at the moment our daughter board is not connected.

PINMUX1 register value is 0x22222220. That is enabled the pinmux for theMcBSP1. This is the "mcbsp Master project" and the pin mux is enabled in function configureMcbsp();

In the SYSCFG module all the pull up/pull down are enabled.

There are no pull up/pull down resistors connected externally.

sinan lezgioglu said:

There are no pull up/pull down resistors connected externally.

On the video it seems that only DX is affected (FSX seems ok). It shows that DX pin is slowly pulled up which to me look like a bus contention.

So you removed R257 and R79? (see schematics page 7) How is SW1 positionned?

Have you double checked that McBSP1_DX1/GPIO0-1 is not touching other signals?

A.

Right, only DX is affected.

R257 had been removed. R79 (I think you mean R253 for GPIO0-1) was not removed. Because the switch position 5 is open. So R253 has no effect.

SW1 positions are:

1-OFF

2-ON

3-ON

4-ON

5-OFF

6-OFF

7-OFF

8-OFF

Yes, McBSP1_DX1/GPIO0-1 is not touching other signals.

Hi,

We reveiewed the SW1 postitions which holds good and appropriately all pull up/pull down resistors are enabled in the SYSCFG module.

But we tried the same code with same modifications as you mentioned above,  and we probed the DX1, FSX1, CLKX1 on SW1.5, SW1.7 & R161 respectively, We are also getting stable FS1, CLKX1 but not the DX1. We are getting the same video which you shared above the FS1 and DX1waveforms which we could see it on our scope.

But with the original code "as-is" (pdk_C6748_2_0_0_0\biospsp_03_00_01\drivers\examples\evm6748\mcbsp\Master) without any modifications on the buf[] content and using for loop and not commenting tasksleep(), we are getting stable DX1, FSX1, CLK1 and when we set a constant value of 0x80 to the buf[] content, the DX1 data is not stable.

We are still investigating more on this.

Thanks & regards,

Sivaraj K

----------------------------------------------------------------------------------------------------------

Please click the Verify Answer button on this post if it answers your question.

----------------------------------------------------------------------------------------------------------

Hello is there any progress about the issue? We want our project hang on now. We are waiting news from you

Best Regards.

Hi,

If we work with  your code changes as you shared in your earlier posts and compare to the logic of the original code, the data Tx. pattern never changes and it is controversy to the Tx. pattern of the original code logic. I mean, if we feed the buf [] content always to 0x80, then the DX1 data follows the pattern as 1000 0000 and it repeats the same pattern for four different instances of time.

But as per our original code, the Tx. data pattern would change instantaneously and it repeats the same tx. data pattern four times ranging the values from 0 to 255 which would repeat four time as the tempcount index for loop would run from 0 to 1023 (BUFSIZE), so, it repeats the same Tx. pattern values ranging from 0 to 255 repeats four times and we do see the stable data on the DX1 pin throughout the FSX1 clock period, thereby due to the pattern repeats, we do see consistent DX1 signal when we use the original code "as-is".

I think, the buf [] content which we feed should make it constant and we choose in a way that, we do have something like the data pattern should switch over as 0x DE ( in bit pattern wise, 1101 1110 ) sothat, we could see continuous data flow over the entire framesync clock period which we guess. But still, we are doing some more experiments on this to determine why it expects the Tx. data pattern should switch over four times ranging from 0 to 255.

Thanks & regards,

Sivaraj K

----------------------------------------------------------------------------------------------------------

Please click the Verify Answer button on this post if it answers your question.

----------------------------------------------------------------------------------------------------------

Hello is there any progress about the issue? We want our project hang on now. We are waiting news from you

Best Regards.

Hi,

We do think, the strategy of the original code logic shouldn't be changed so that, the tx. data pattern never changes and continuously we observe a stable signal on DX1 pin on the scope accordingly as per we feed the data bit pattern to the buf[] content.

It is recommended not to change the strategic approach of the original code logic and kindly try to use the example "as-is".

Thanks & regards,
Sivaraj K

Are you aware of the insight of your "answer".

We are not some curious people doing a hobby work about DSPs .

We are not writing our comments to a PC magazine regarding some examples given.

We are not some uni students who are evaluating some ICs and preparing a homework.

We are not playing with the example "as-is" and trying to see what kind of results we get as we modify it. The fact is that we are not even interested in the example "as-is".

WE ARE TRYING TO MAKE THE MCBSP WORK.

And I think we made our problem clear for those who want to understand with good intentions.

We are working on this for our near future products.

We have been using a DSP of Freescale. For our next generation products we have chosen TI's DSPs. We are not newbies to this subject.

Our own designed and developed products with TDM buses based on Freescale's DSPs have been on the market for 5 years.

We are stuck at this MCBSP stage and have been asking for support.

We might be doing something wrong or we might be missing a point,

or there is something wrong with the drivers

or there is something wrong with the hardware.

Whatever it is we need a solution not an excuse.

hello is there any progress about the issue we are waiting news from you. it is more than 1 month have been passed, we did not solve problem

see the below post for the result of the investigation:
https://e2e.ti.com/support/dsp/omap_applications_processors/f/42/t/429267