Strange behavior of the McASP transmitter section !!!

Hi,

Thanks for your post.

I have one guess as of now, which are WNUMEVT and WNUMDMA values and these values needs to be set before enabling the write FIFO in the WFIFOCTL register. Also, there are some criteria in setting these values to meet the number of mcasp serializers to be used as transmitters which are below:

WNUMEVT: This value should be set to a non-zero integer multiple of the number of serializers enabled as transmitters.

WNUMDMA: This value must equal the number of McASP serializers used as transmitters.

Kindly check, If the Write FIFO is enabled, upon a transmit DMA request from the McASP, the WFIFO will write WNUMDMA 32-bit words to the McASP only if there are at least WNUMDMA words in the Write FIFO.

Note that if transmit DMA event pacing is desired, WFIFOCTL.WNUMEVT should be set to a non-zero integer multiple of the value in WFIFOCTL.WNUMDMA. If transmit DMA event pacing is not desired, then the value in WFIFOCTL.WNUMEVT should be set equal to the value in WFIFOCTL.WNUMDMA.

You could also check the status of write level and you can read the number of 32-bit words currently in the write FIFO through WFIFOSTS register.

Thanks & regards,

Sivaraj K

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

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

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

Hi Sivaraj

Thanks for the reply. You recommendations are the general assumptions that should be taken into account. Since the RX section is working fine, I believe having all of TX settings also correct. Maybe you can provide more detailed information related to TX multi-serializer initialization or the best way a sample code?
In your post you’ve mixed McASP and McBSP. What is it – a typo or you mean the behavior should be the same?

Kindly

GenPol

Hi,

Yes, it is typo error and it is corrected now in the above post. 

Let me check on the above request and will update you.

Thanks & regards,

Sivaraj K

Hi,

I don't think, logicPD OMAPL138 experimenter kit does provide sample code for McASP with FIFO and EDMA and I believe, there is a sample code available to test audio using AIC3106 codec. There are BSL and GEL files which are downloadable from logicPD support website but it needs an account to downlaod which you shall create an account to download the same. The same info. is given below under Software files:

http://www.logicpd.com/_archived_drupal_site/products/development-kits/zoom-omap-l138-experimenter-kit#tabs-som-2

After creating an account, you can download all software and hardware collaterals and software tools, BSL test code etc from the below:

http://support.logicpd.com/ProductDownloads/OMAP-L138SOM-M1(eXperimenterKit).aspx

Thanks & regards,

Sivaraj K

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

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

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

Dear Sivarai,

thank for the reply. Obviously you were not enough focused on my questions.
My questions were neither about McASP RTM, nor about Experimenter board and how to download something from LogicPD, nor about board initialization for AIC3106, having no multi-serializers connection at all, etc.

But I’ve asked about more detailed information related to TX multi-serializer initialization using WFIFO. If you have some info please let me know.

Kindly

GenPol

Hi,

Thanks for your update.

Steps to intialize Tx. Active serializer:

1. First, configure the appropriate active Tx. serializers (AXRn) required for your application through Serializer registers: SRCTL[n].

2. In order to activate the Tx. serializers, please see the steps below:

          (a) Before starting, clear the respective transmitter status registers by writing XSTAT = FFFFh 
          (b) Take the respective serializers out of reset by setting the XSRCLR bit for the transmitter in GBLCTL. All                    other bits in GBLCTL should be left at the previous state.
          (c) Read back from GBLCTL to ensure the bit(s) to which you wrote are successfully latched in
               GBLCTL before you proceed.

To my knowledge, the above procedure would be common for transmit active serializer configuration and activating the same, irrespective of whether WFIFO is enabled or disabled.

Basically, the McASP Audio FIFO (AFIFO) provides additional data buffering for the McASP. The time it takes for the host CPU or DMA controller to respond to DMA requests from the McASP may vary, so, the additional buffering would be provided by the AFIFO which allows greater tolerance to such variations

Whether the WFIFO is enabled or disabled, the McASP generates transmit DMA requests as needed and the AFIFO would be invisible to the McASP in this case. If the Write FIFO is enabled, transmit DMA would request from the McASP and are sent to the AFIFO, which in turn generates transmit DMA requests to the host/DMA controller.

Thanks & regards,

Sivaraj K

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

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

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

Hi Sivarai,

Thanks for  the reply. I’m absolutely agreed with your init sequence in pp. 1 and 2. It looks like this also in my app:

// clear transmitter and receiver status register

               MCASP->XSTAT = 0x0000FFFF;
               MCASP->RSTAT = 0x0000FFFF;

// take the serializers out of reset

                SETBIT(MCASP->XGBLCTL, XSRCLR);
                while (!CHKBIT(MCASP->XGBLCTL, XSRCLR)) {}

                SETBIT(MCASP->RGBLCTL, RSRCLR);
                while (!CHKBIT(MCASP->RGBLCTL, RSRCLR)) {} 

But FMPOV the stumbling block is lying some lower.
On the next step, if you use one serializer only, you should check, whether the XDATA bit in XSTAT is cleared to 0.

                while ( ( MCASP->XSTAT & 0x00000020 ) != 0x00000000 );

But if you use multi-serializers and WFIFO you should preliminary fill the WFIFO. The tested scenarios I described shortly in my initial post: filling WFIFO and waiting for XDATA, filling WFIFO fixed times, manual triggering the first transfer.

The first and third ways bring nothing – the EDMA3 transfer doesn’t start, the second way originates in the above described issue. What else could be useful to get the XDATA correctly?

Kindly

GenPol

Hi,

Thanks for your update.

Usually, If the Write FIFO has space to accept WNUMEVT 32-bit words, it generates a transmit DMA request to
the DMA controller and then, it waits for a response. Once WNUMEVT words have been written to the FIFO, it checks
again to see if there is space for WNUMEVT 32-bit words. If there is space, it generates another transmit
DMA request to the DMA controller, and so on. In this fashion, the Write FIFO will attempt to stay filled and will trigger the EDMA3 data transfer.

It keeps Write FIFO filling and never stops, if it stops filling then EDMA3 transfer would stop obviously, So, it is recommended to always maintain in a fashion that, it should keep attempting to fill the Write FIFO and will never fail in normal case. In case, if it fails to fill the Write FIFO at any time instance, EDMA3 transfer would stop automatically.

Thanks & regards,

Sivaraj K

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

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

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

Hi Sivaraj,

thanks for the reply. I'm now in vacation and have no access to my HW/SW. So I would propose to continue the discussion approx. 2 weeks later.

Kindly

GenPol

Dear Gentle(wo)men,

Shortly about my last progress steps:

I was able to initialize the McASP with RFIFO/WFIFO pacer and EDMA3 and correctly receive/transmit the data, using 32-bit McASP and EDMA3 access (ACNT = 4, RFMT/XFMT.RSSZ = 0xF);
I was also able to initialize the McASP with RFIFO pacer and EDMA3 and correctly receive the data, using 16-bit McASP and EDMA3 access (ACNT = 2, RFMT.RSSZ = 0x7) as described here:
http://processors.wiki.ti.com/index.php/McASP_Tips
But I wasn’t able to do the same for the transmitter section, using 16-bit McASP and EDMA3 access (ACNT = 2, XFMT.RSSZ = 0x7). The issue descriptions please see above.

For some tips and ideas, how to initialize the system correctly (if it at all possible?), many thanks in advance.

2Sivaraj@ti
If you want to contribute something, please don’t cite the RTMs more!!!. A few lines of code will be better!!!.

Kindly

GenPol