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.

Reading multiple McASP channels using EDMA on C6713

Hi,

I have a custom board with a C6713 DSP.  The board has two ADS 1278 ADC converters and these connect to the C6713 using the McASP1 device.  So, the data stream from one ADC goes to channel 0 of McASP1 and the second ADC goes to channel 1 of McASP1 (note that McASP0 is unused).

To begin board testing I have built a simple application that uses ping-pong buffering via EDMA to store the data from ADC0.  The EDMA is driven from McASP event EDMA_CHA_REVT1.  In this test only one serializer on the McASP is enabled - the one for channel 0.  When a new buffer is full the EDMA interrupt is used to trigger the application to process the data.  This application works absolutely fine and I see the ADC input data in the ping-pong buffers and the application is triggered via the interrupt at the correct rate.

For the next test I enabled also the serializer for channel 1 and assumed that the data from both ADCs would now appear in the ping-pong buffers.  As an additional check I put a scope on the ADC pins to confirm that both ADCs are being clocked and Fsynced correctly and that they are both outputting a data stream and indeed this is the case.

What happens now with this test is that the application no longer runs.  It seems that the interrupt never gets raised.  Further, if I do some debug into the ping-pong buffers it seems that only a single data sample gets stored there.

Clearly some additional setup is required to drive this two-channel configuration.  This is where I am not clear on some points.  For example:

Does the single event EDMA_CHA_REVT1 get raised for any/all of the McASP1 channels or are there separate events for each channel that need to be handled individually?

Do I need to replicate the EDMA channels that handle channel 0 for channel 1 or can one set of ping-pong buffers and EDMA channels handle any number of McASP channels?  If this is the case then why does the application hang when I enable the second serializer?  What I assume at the moment is that McASP channel 1 has data available but there is nothing there to deal with it and so the whole thing stops pending something reading the data.

The ADC is a multi-channel device.  On each Fsync it sends 8 channels worth of data from the 8 analogue inputs and the EDMA stores this in the buffers. Again, for the single ADC test this works fine.  For the two ADC configuration how would the data get stored in the buffers?  Would it be 8 channels from ADC0 followed by 8 channels from ADC 1 or ADC0-ch0; ADC1-ch0; ADC0-ch1; ADC1-ch1 etc etc - or something different?

Any help to understand these points greatly appreciated.

  • Mike Bardill said:
    Does the single event EDMA_CHA_REVT1 get raised for any/all of the McASP1 channels or are there separate events for each channel that need to be handled individually?

    Typically an EDMA event is generated once every time slot for McASP TDM mode. I assume (correct me if I'm wrong) that both ADC's are being clocked from McASP1 and are synchronized with respect to the bit clock. If this is the case, you will need to read the data from both Serializers (Channel 0, Channel 1) at each event.

    When the McASP Event occurs, you'll need to initialize the EDMA to make two transfers since you only get 1 EDMA event per time slot.

     - 1 32 bit read from RBUF0 register

     - 1 32 bit read from RBUF1 register

    Alternatively sequential two reads from the DAT port will accomplish the same thing (assuming both ADC's are synchronized), and is highly recommended (mainly because it results in faster accesses from the McASP when multiple serializers are read)

    One way to do this would be to utilize the completion of the transfer from ADC0 to trigger an transfer from ADC1.

    Assuming you have the EDMA set up correctly, there should be no issue with using the same buffer space to store samples from both ADCs - though you may wish to increase the size of your buffer. You could alternatively make two individual buffers - one for each ADC. It's up to your preference.

    Secion 3.3.5 of the C6000 McASP User's Guide (TI Literature Number: SPRU041J) has a good diagram of this

     

    Mike Bardill said:
    What happens now with this test is that the application no longer runs.  It seems that the interrupt never gets raised.  Further, if I do some debug into the ping-pong buffers it seems that only a single data sample gets stored there.

    When an Rx buffer is not serviced in time (i.e. before the next time slot starts), the McASP generates a buffer Overrun Condition. If an interrupt is not getting raised, this typically means the internal state machine of the McASP detected a catastrophic error (loss of synchronization between DMA and Reciever). At this point, the McASP needs to be reset.

    Secion 3.5.5 of the C6000 McASP User's Guide (TI Literature Number: SPRU041J) explains all the error conditions that would cause the McASP to halt.

    Also note - that the McASP doesn't support emulation halting. (i.e. if you try to halt the McASP in the middle of operation, it will treat this as an error condition on purpose), and you'll need to restart the McASP.

     

    You can use Digital Loopback Mode (DLB) in the McASP Peripheral to debug as well.

     

  • Drew,

    Thanks for your reply.  I have set the McASP and EDMA up pretty much as you describe and it is all working fine now.  The main change was to move from an event synchronised configuration to a frame based 1D config.  On each event the EDMA transfers 1 sample from ADC0 and 1 sample from ADC1.  The ADCs are clocked at 40Khz (Frame Sync) and there are 8 events per frame as each ADC has 8 analogue channels; 16 samples per frame.  Some driver software sorts the stored samples from the EDMA ping-pong buffers into contiguous streams for each analogue channel.

    Indeed the buffer overrun error was being raised previously; this has now gone away.

    Regards,

    Mike.