L138 McASP transmitting alternates channels

It appears AXEVT is triggered on every active time slot no matter what (time slots 0 and 1 in my case for I2S Transfer mode). Is there any way to prevent this? Or do I just need to use a different transfer mode like Burst?

Marshall,

This is actually the desired behavior for most McASP transfer modes where data needs to be packed on the line all the time (no data gaps).  If you do not need to transfer continuous data to an external component, the burst mode works well.  Using the chip-level McASP FIFO can cut down on the number of generated events, but it still expects to keep the data line packed.

-Tommy

I want and need continuous data to stream to an external device, however, I need to control over which channel the data is sent on. In I2S the lower part of the frame sync shows the left channel, and I need that to be left channel data - when sometimes after reset the event could of been generated from the right channel first.

I did find documentation on AXEVTE and AXEVTO to signify an event triggered by odd/even slots, however, my device does not have this option.

Maybe I'll just have to figure out how to do Burst mode instead?

Marshall,

When you say that the left/right is switching, which component is switching?  Is it L138 or the external component?

-Tommy

Tommy -

I have the L138 McASP connected to an AIC3204. When the McASP begins transmitting data, it appears as if it is random which channel the data will show up on, left or right. Both the frame sync and bit clock are generated on the AIC3204, thus external clocks to the L138.

For example, I set up my test and run it and the data shows up on the left channel. Now if I perform a reset and run my test again, this time the data may show up on the right channel and crashes. I am convinced this is because when I release the serializers, whichever event comes first (AXEVTE or AXEVTO) on my 2-slot TDM transfer mode, then determines which channel I will send on. However, my device does not appear to have an option to being transfer on these special AXEVTE/AXEVTO events, only AXEVT.

This seems to be the case on both on transmit and receive.

Marshall

Marshall,

Are you performing a full system reset between runs?  It may be possible that the EDMA or McASP state machines are still running in the background if the device is only getting CPU resets or restarts.

The McASP should be looking for the edge type (rising/falling) specified by its configuration so I would not expect it to be reversing slots between runs.

-Tommy

Tommy,

Yes, even after full system resets the problem persists. The McASP is configured for falling edge for start of frame (time slot 0).

There is a comment in McASP User's Guide (SPRUFM1 Aug 2009), section 2.4.1.2, and step 11. "Upon the first frame sync signal, McASP transfers begin. The McASP synchronizes to an edge on the frame sync pin, not the level on the frame sync pin. This makes it easy to release the state machine and frame sync generators from reset. For example, if you configure the McASP for rising edge transmit frame sync, then you do not need to wait for a low level on the frame sync pin before releasing the McASP transmitter state machine and frame sync generators from reset."

This makes me also believe that this error in behavior is impossible. I have verified the bit in AFSXCTL->FSXP does get set to '1'.

Really appreciating your help and ideas,

Marshall

Changing over to Burst/DSP mode rather than I2S mode seems to do transfers perfectly how I need them and be a sufficient solution for the time being. Only concern is that TDM mode seems more tailored to what I need as Burst Transfer Mode is described to be useful for "nonaudio", which the data I am transferring is audio.

Now to figure out how to make the AIC3204 produce a DSP/Burst Frame Sync rather than the I2S FS.

Marshall

Marshall,

Glad that you have a work-around.  I was talking to a colleague about this issue and he mentioned that sometimes the McASP can exhibit strange behavior if the intialization sequence is incorrect, especially when clocks are externally sourced.  The internal McASP logic also uses those clocks for reset / init.

-Tommy