This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

OMAP-L137, McASP, TDM, I2S

I'm planning on using the McASP1 to transmit 2-slot I2S data. I'd like to handle the transmit and receive with the CPU (not DMA) because I have 2 32 bit words to transmit and receive, but they are transmitted and received seldomly. That is, I do not have an audio signal, but instead am driving an ADC/DAC chip that talks I2S.

DMA seems like overkill for two 32 bit words. I expect the receive and transmit channels to be synchronous. Will the shift registers allow me to perform this:

write, write, read, read

or will I need to

write, read, write, read?

That is, if I don't read the first slot's data before the second slot's data is shifted in, will the receive shift register hold the data? (I expect no additional receive data to come in before I read both slots of data).

  • Flamingo,

    I'm not a McASP expert, but my understanding is that the Transmit and Receive buffers operate independently so you should be able to queue up transmit data, start the synchronous operation, and then read back the receive data.

    -Tommy

  • I think that may be true in the "general case" but I'm not so sure with the synchronous case (when the xmit clocks are used for the rclks too).

  • Can you elaborate on why this would not work for synchronous operation?

  • There is one 32-bit transmit register for each pin (16 in all). There is one 32-bit receive register for each pin (16 in all). In my case, AXR1_0 is the output, so XBUF0 is my transmit data register. AXR1_4 is the input, so RBUF4 is my receive data register. Paragraph 2.3 of SPRU041j says that each has a shift register. I can't access the shift registers directly, but let us call them XRSR1_0 and XRSR1_4.

    Assume all references below are for McASP1. So when I transmit 2 slots manually (not DMA driven), I presume that I'll

    1. clear the XDATA bit in XSTAT. Clear the RDATA bit in RSTAT.

    2. write a transmit word to XBUF0.

    3. wait for XDATA to be 1 (indicating that XBUF(all) have transferred to XRSR(all)).

    3. clear XDATA bit in XSTAT.

    4. write the second slot's transmit word to XBUF0.

    At some time during these steps or shortly after, the first transmit data word will begin shifting out of XRSR0. At the same time (because we are synchronous), the receive data will begin shifting into XRSR4. At some point, all of the transmit bits for the first word are out and at the same time, all of the receive bits for the receive word are in the shift register. The receive data in XRSR4 will go through masking/rotation/etc and be transferred to the RBUF4. The transmit data buffer (the second slot's info) will transfer into the XRSR0. XRSR0 will be shifted out while the second slot's receive data is shifted into XRSR4. Once the transmission is complete, the receive data in the shift register will also be complete. It will be ready to transfer to RBUF4.

    At this time, there is a 32 bit word in RBUF4 and a 32 bit word in XRSR4. As you can see, the transmit and receives are not independent. They use the same clock and continue at the same rate. Now the question is, if I transmit no more data (thus generating no more clocks), will the data sitting in XRSR4 stay there until I read the RBUF4? or will it signal an overrun error because it can't yet shift out? Or will it generate an overrun error AND transfer the data to RBUF4.

    Possibly there is a buffer inside the OMAP that buffers received data. I know this is true for other peripherals. In which case, it could be that none of the options is true.

    If I perform write, write, read, read, it will work if either the data is internally buffered or if the data stays in XRSR4 until I read the data in RDAT4.

    If I perform write, read, write, read, it will work either way, but the transmitter/receiver will include dead time.

    In the "independent" case, the transmit clock is not used to clock in receive data, so the receive data would wait until I read it. Not true here. (PS: the AK4556 chip does not allow for both transmit and receive clocks. It expects synchronous transmit/receive.)

  • Flamingo,

    I assumed that you were going to use the McASP FIFOs.  If not, then yes, you are correct that you would have to service the Tx/Rx buffers after each frame.  But if the FIFOs are used, you should be able to do a wrt-wrt-rd-rd.

    -Tommy

  • SPRU041j does not mention a McASP FIFO. Where would I find the documentation for it?

    Also, SPRU041j does say that I2S is supported via TDM. I find discussions of burst mode also. The documentation for the peripheral says it speaks I2S. My HW engineer says that I only need to transmit to the device once (until the value changes, and then I have to transmit again). That seems to match the description for "burst mode". If I set up everything for the McASP as described in the TDM initialization, except that I put the device in burst mode, does that mean that I only see frame sync when I write to XBUF?

  • Flamingo,

    SPRU04J is the generic McASP user guide for C6000 devices.  OMAPL137 has a slightly modified implementation of McASP and has its own user guide identified as SPRUFM1.  The document includes register descriptions for the McASP FIFOs.

    The burst transfer mode will only generate a framesync when you write data to the transmit buffer.

    -Tommy