OMAP L-137/C6747 McASP burst mode with PSP driver

Hi Marco,

I believe the audio example uses McASP in burst mode:

C:\Program Files\Texas Instruments\pspdrivers_xx_xx_xx_xx\packages\ti\pspiom\examples\evm6747\audio\

Thank you Mariana, I see the example uses burst mode ( .afsrctl  = 0x00000000 ) but the example is an audio example. In my application I would like to use McASPs as a data transfer path between 2 DSPs. This data transfer happens only sometimes but not always, so i should have frame syncs moving only when the master DSP is writing something. I don't think McASP driver is capable of this because its DMA setup should be designed for continuous audio transmission. But maybe I am wrong and can use TI's McASP driver for this operation as well... any one can help?

Hi,

did you manage to use the driver in burst mode?

No, sorry. I tried different configurations but it seems that the driver is designed to sustain the frame sync signal (with the loop-job buffer I think). Since I don't have many time in doing this, I think I will use the normal TDM mode for data transfer, using one of the slots as a data information container useful for synchronization. When the transfer will be inactive i will close the streams and reopen them if necessary. In my system this should work well.

It would be nice if TI will add more examples on McASP PSP folder showing all modes of operation.

Right.

I've recompiled the driver without the loop-job, but as soon as the frame sync stops because the data burst is transmitted, the driver stops working.

What version of PSP are you using?

pspdrivers_01_30_00_05

The upcoming PSP pspdrivers_01_30_00_06 has fixes that might solve your problem.

Please wait until it is posted at the link below and test it again (I do not have a time frame but it should not take long).

https://www-a.ti.com/downloads/sds_support/targetcontent/psp/bios_psp/index.html

It seems that we absolutely need this burst mode... When will the new driver will be released?

Thank you.

Mariana,

Can you confirm PSP version 01.30 fixes the burst mode issue?  I have version 01.20 now and burst mode can't be used inthe McASP driver as frame syncs will always be active, regardless of whether or not data is actively being transmitted.  I'm trying to use the McASP tx to burst data over to an external device.  The C6747 is master so is providing the CLK and FS signals.

thanks,

Mike

Hi Mike,

Yep, it was fixed.

Mariana,

In what version was the fix?  I downloaded PSP 01.30.00 but after rereading this post it seems the problem may still be present in that release.  I looked at the release notes for the releases up to 01.30.06 but there is no mention of a "burst mode" fix.  I have been trying to verify with 01.30.00 but since 01.30.00 is based on newer versions of CCS and BIOS, I 've started to upgrade everything (e.g. EDMA3, CCSv3.3 -> v4 and BIOS 5.33 -> 5.41).  That is currently slowing me down.  I don't want to go through all this upgrade work only to still not have a working burst mode. 

In the past I have tended to only stick with GA releases and based on the numbering scheme, I guess PSP 01.30.00 is the latest GA release.  Isn't it somewhat "risky" to use a non-GA release?

Also, when would an application use or not use loop job mode in the McASP driver?

thanks,

Mike

Mike,

I asked for the PSP to take a look at your question.

Mariana,

I have a couple more questions about the PSP drivers posted here:

http://e2e.ti.com/support/dsp/tms320c6000_floating-point_dsps/f/115/p/41058/143060.aspx#143060

Could you pass these onto the PSP dev team as well?

Also, I may have implied in a previous post that PSP 01.30.00 was an older release compared with 01.30.05.  But I think the 01.30.00 (e.g. GA) is the newest version.

I did the sample application and it does look like burst mode works.  I need to do some more checking before I can completely verify, though.  I had to recompile the library in non-loopjob mode.  In 01.20.00 I don't think there was a compile option for this mode.  I just passed a NULL pointer for the loopjob buffer when I didn't care what was transmitted/received during idle times.  What limitations are there when the library is compiled in non-loopjob mode?

thanks,

Mike

Mariana,

Have you heard back from the PSP team?

Mariana said:

Mike,

I asked for the PSP to take a look at your question.

I did some more testing with the PSP 01.30.00.  The burst mode works but has limitations that are presenting problems for our design.  Or maybe I'm just not setting things up correctly.  This version of PSP actually ships with a new example (not in 01.20) called "mcasp sample master/slave".  This operates in burst mode.  The program goes through 2 options.  I'm only interested in the first option which is only a single SIO buffer.  This means I fill a packet with data, send the data over to the receiving device, then wait some time and repeat.  The sample program does this as is.  When I start modifying some parameters it no longer works.  The parameters I modify are TSK_sleep() interval (e.g. time between successive transmit bursts), BUFSIZE (e.g. bytes per burst frame of the SIO), and the ahclkxctl field of the McASP registers (e.g. increase the clock speed).

The TSK_sleep should determine the amount of time between bursts.  Our application requires many short bursts of data coming very quickly.  So I decreased this time from 1000 (e.g. 1 second) to 10 (e.g. 10 ms).  When I monitor the bursts on an O-scope, the bursts are not 10 ms apart.  They are more like 26-27 ms apart.  Why is there so much delay?  Is this the PSP s/w or in the McASP peripheral itself.  For our application, the bursts will be coming about 30us apart.

The next parameter I try to modify is BUFSIZE.  The default for this is 2560 x 2 = 5120 (bytes).  This is way too big for our design.  I tried to cut it done by a factor of 10 to make it 256 x 2 = 512.  The program aborts during the call to the first SIO_reclaim.  It hits an assertion here:

Assertion failed, (0 != timeout), file C:/Program Files/Texas Instruments/updates/pspdrivers_01_30_00/packages/ti/pspiom/mcasp/src/Mcasp.c, line 3902

Why does the size of the buffer need to be so large for burst mode to operate properly?  Is it possible to reduce the size?  For our application, we would like the size to be only 128 bytes.

The third parameter is ahclkxctl value.  The default is 0x0000 8004.  This will divide the input high clock by 5.  Our application needs to run the McASP clock at the max rate so this value needs to be 0x0000 8000.  When I change this so the McASP clock runs at a higher rate, I get the above assertion more frequently.  To be specific, if I keep the BUFSIZE at default and increase the clock speed by 5, the program will still work.  If I reduce the BUFSIZE by a factor of 2, the program will abort at the above mentioned assertion.  Now if I change the clock back to the default setting (e.g. /5), the program will work at the reduced buffer size.  So there seems to be some type of trade-off with the size of the buffer, the speed of the McASP clock, and reaching the assert statement above.  Can you explain why this is?

Based on our criteria, will we be able to use burst mode for our design or will we need to redesign our interface?

design criteria: send 128 bytes (e.g. 32 32-bit words) from the C6747 DSP to an external device (FPGA).  These bursts (e.g. frames) need to happen every 12kHz (ofr83.8 us).  We planned on running the McASP clock at 19.2 MHz to send the 128 bytes in 53.3 us.  This leaves ~30 us between each short burst of data.

thanks,

Mike

Hi Mike,

Sorry for the delay in the respone.

I will look in to this along with the other queries and get back to you soon.

thanks,

imtiaz SMA

Hi Mike,

The latest version of PSP package is 01.30.01. The difference between the 01.30.00 and the latest version is

1.     Added support for the uPP driver.

2.     Bug fixes for the other drivers.

The latency you see is because of the software.

The Non loop job mode is a special mode for the Mcasp driver mainly used for the data transfer. This requires special handling on the part of the driver as there is chance of underrun/overrun errors occurring on the Mcasp(when no data is available especially during the single packet operation). Also it is required to do some additional checks (e.g. all the data  in FIFO is transmitted etc.) before stopping the frame syncs and completing the processing of the packet. This requires some waiting on the part of the driver. Hence the driver does these operation in the context of a SWI(rather than the interrupt context of the EDMA completion).Thus there is an inherent delay between the processing of the two successive packets.

Regarding the problem with the “buffer size”  and the “clock rate” I am able to reproduce the problem and debugging the same to check if it is a problem in the SW or HW.

Thanks & Regards,

Imtiaz SMA

Thank-you again for the help.  This is still an ongoing issue for our design.

Imtiaz SMA said:

The latest version of PSP package is 01.30.01. 

Any reason we need this latest version for our C6747?

Imtiaz SMA said:

The Non loop job mode is a special mode for the Mcasp driver mainly used for the data transfer.

I assume this means burst mode operation? So if we are NOT using burst mode we should build the library with "Mcasp_LOOPJOB_ENABLED" defined?

Imtiaz SMA said:

Regarding the problem with the “buffer size”  and the “clock rate” I am able to reproduce the problem and debugging the same to check if it is a problem in the SW or HW.

Please let me know your findings on this.

thanks,

Mike

TI Team,

Can you please respond to Mike's request?

-John

Imtiaz SMA said:

Regarding the problem with the “buffer size”  and the “clock rate” I am able to reproduce the problem and debugging the same to check if it is a problem in the SW or HW.

 

Hi Imtiaz SMA,

  I also confronts with the same assertion failed (0!=timeout), in Mcasp.c, ling 3683.

  while ((((instHandle->hwInfo.regs)->GBLCTL & bitMaskVal) !=
            bitMaskVal) && (timeout > 0))
        {
            /* reduce the retry count value                                   */
            timeout--;

            isTask = TSK_isTSK();
           
            /* wait for 1 tick only if called from a task context             */
            if (TRUE == isTask)
            {
                TSK_sleep(1);
            }
        }

        assert(0 != timeout);

  Hope you can find the problem as soon as possible

Bo Li

Has there been any resolution on this?  I am affected by this as well.

I can confirm that the following code is causing the problem when the transfer size is small or clock rate is high.

Here is the description of what happens (problem).

• Mcasp_localLoadPktToEdma() calls Mcasp_localActivateSmFsForXmt() which in turn calls mcaspBitSetGblXCtl() to generate frame sync.
• In side mcaspBitSetGblXCtl(), you can see the following code which tries to set and poll the XFRST bit (bitMaskVal = 0x1000) to make sure it is 1. If it the bit is not read as "1", the calling task will sleep for 1ms.
• What happens is that if during the 1ms interval, the short transfer has completed already. The interrupt is raised (see Mcasp_localEdmaCallback()) which posts the swi function Mcasp_swiTxFifo(). Mcasp_swiTxFifo() calls Mcasp_localDeactivateSmFsForXmt() to de-generate frame sync.
• Now, after TSK_sleep() returns, you will never see the XFRST bit being set because Mcasp_localDeactivateSmFsForXmt() has already de-generated the frame sync. And that's why you will see the assert(0 != timeout) error.

Bo Li said:

Regarding the problem with the “buffer size”  and the “clock rate” I am able to reproduce the problem and debugging the same to check if it is a problem in the SW or HW.