Please note as of Wednesday, August 15th, 2018 this wiki has been set to read only. If you are a TI Employee and require Edit ability please contact x0211426 from the company directory.

McASP Tips

From Texas Instruments Wiki
Jump to: navigation, search


This page should be applicable to all TI devices with the McASP peripheral. Note that the "ASP" that was in devices such as DM6446 is NOT related to McASP.

The only thing that differs from one device to another with the McASP peripheral is the presence of a FIFO. The Audio FIFO (AFIFO) was added in the OMAP-L138 and is now a standard feature of the McASP going forward in devices such as DM8168, DM8148, etc. Check your device-specific documentation if you're not sure whether your device supports the AFIFO.

Common Issues

Transmitter underflow

When the McASP underflows (underruns) the result is that the McASP stops outputting data altogether, i.e. it clocks out zeros. The only way to make it output data again is by resetting the McASP. This condition is fairly easy to detect by looking at the XSTAT.XUNDRN field. You can get an interrupt when this occurs by setting XINTCTL.XUNDRN.

If you're never getting data out of the McASP you should carefully examine your initialization procedure. If you don't precisely follow the startup procedure it is easy to underflow right at the beginning which makes it seem as if it never started.

Port inconsistency

There are two different ways to supply data to the McASP:

  • Config port (XBUFn/RBUFn)
  • DMA port
    • This port, despite its name, is allowed to be written with CPU or DMA
    • The address of this port would be found in the device-specific memory map. It would often have a name such as "McASP0 Data".

The correct address where data should be written/read needs to be consistent with the programming of XBUSEL/RBUSEL. When XFMT.XBUSEL=1 (RFMT.RBUSEL=1) you should use the Config port registers. For XBUSEL=0 (or RBUSEL=0) you should use the DMA port address.

32-bit Access Requirements

Strictly speaking, the McASP accesses should always be 32-bit accesses. This makes it tricky if you're dealing with 16-bit data. There are a few ways to handle this:

  1. One option is to increase your buffer size such that all of your 16-bit data consumes a 32-bit word, i.e. turn your array of uint16_t data into a uint32_t array with padding on each word.
  2. Another option if using DMA is to set your element size to 4 bytes, but your data incrementing to only 2 bytes. This way you're always doing a 32-bit access where half of the data is being discarded. You may need to use XROT/RROT=16-bit in order to get the data in the proper half of the shift register.
  3. An unofficial option that is frequently used is to simply enable the Audio FIFO.
    • This is not officially supported, i.e. 16-bit accesses are "undefined" for the McASP, but it is widely used in any case.
    • You cannot do "packed accesses". For example, if you're using EDMA you need to make sure the indexing on the McASP FIFO is set to 0 because otherwise the EDMA will pack data together which won't work.
    • When enabling the FIFO you would set WNUMDMA equal to the number of transmit serializers in use. You set RNUMDMA equal to the number of receive serializers in use. The NUMEVT field should be a multiple of the number of corresponding serializers.
    • You may need rotation by 16 bits to get the data in the proper half of the shift register, e.g. XROT/RROT = 16-bit.