• State Resolved
  • Locked Locked
  • Replies 11 replies
  • Subscribers 30 subscribers
  • Views 1722 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

RM48L952 ADC Data Capture Question

stomp
Genius 4675 points

Hi,

In our system we need to capture a 40khz signal after a trigger for a total time of 120mS, across 3 channels.  Its important that the sample time offset is known between each channel. Ideally I want to sample above nyquest for this signal and the sample to take place on a hardware triggered event. Each event will have about 9600 samples x 3 channels. In the future we would want to use 16 channels.

We understand the channel sequencer will store each channels conversion sequentially in the ADC buffer RAM, and then we plan to use DMA to transfer from ADC RAM to 3 memory arrays for signal analysis.

We need some clarification about the storage of the data.

  1. Is the ADC RAM and the ADC Event Group FIFO (ADEVBUFFER) the same thing?
  2. How do we setup the DMA for this?. Do we just DMA from the Group FIFO, or from ADC RAM? (more worried about DMA completion before the next sample complete)

  3. Is there any known method of taking each conversion result (knowing how they are spaced in ADC RAM) and transferring to a linear block of SRAM?. It is better to trigger 3 separate DMA requests for each channels results, or is there another method?

Any help, as always, is much appreciated.

Thanks

Stomp!.

  • 0
    TI__Mastermind 22375 points

    Stomp,

    1] The ADC RAM is where the result are stored.
         The CPU or DMA can read the conversion results in one of two ways:

    1. By using the conversion results memory as a FIFO queue.
    2. By accessing the conversion results memory directly.

    These information is available in chapter 19.3.9 "How to Read the Results' Memory" in RM48 TRM (spnu503b)


    2] If I understand your application (at least for now) your group event is configured to convert 3 channels.
        The data in RAM will be Channel x, Channel y, Channel z ......)
         Using the fifo, you will have no control to read the conversion for a specific channel. The read will happen in sequence (x, y, z)
         Using the memory directly, you can select which channel to read by using the correct offset from ADC Ram.
         ADC can generate a DMA request after a fixed number of conversion.

    3] There is only 1  ADC DMA request per group.
         One option could be to configure the ADC to generate a DMA Request every 3 write to buffer. (Each completion of an evt group)
         On the DMA side, a transfer group can be defined as a Frame Transfer of x Frame of 3 element. (x = 9600 in your case)
         The element in this case is a conversion result, 3 element because you have 3 ADC channel. DMA is also configured in AUTO_INIT.
         1 DMA request from ADC is necessary for each 3 conversion.
         

    I've prepared an example where 16 x 3 conversion are transferred with DMA to a data buffer. Using Element Destination Offset, the data will be organized per channel. When all conversion are finally transferred, the DMA will stop.
    To optimize the SRAM usage, I only store the conversion data value without the channel ID. Each conversion is 16 bites. The DMA reads from ADC the relevant 16 bits and store them in SRAM.

    8304.ADC_DMA.zip

  • 0 in reply to Jean-Marc Mifsud
    Genius 4675 points
    Hi Jean-Marc,

    Thanks very much for your time in preparing the sample. It has gone a long way to helping us understand the operation of the ADC under DMA conditions.

    For our solution we will need to trigger the DMA on every ADC conversion and move that conversion result to a different target array otherwise the software overhead for our application will warrant us moving to a dedicated DSP.

    Thanks again for your time, it solved our problems.

    Cheers
    Stomp!
  • 0 in reply to stomp
    TI__Mastermind 22375 points

    Hi Stomp,

    Good to know that will solve your problem.

    Anyway I don't understand your modified solution.


    In my proposal, the 3 (or more) channels will be reorganize in 1 buffer via DMA. Because I'm using element offset, the target buffer (Data) will appear as 3 distinct buffers. It could be defined as a structure of 3 array allowing you a direct access via CPU.
    For the 1st one the base address is Data+ offset=0x00, the 2nd one is Data+ offset = element offset and the 3rd one is Data+ offset = 2 x element offset.
    The element offset in the control packet can be resized to accommodate more data.

     
    For my personal knowledge, I will appreciate if you can detail your final approach.

  • 0 in reply to Jean-Marc Mifsud
    Genius 4675 points
    Hi Jean-Marc,
    We have stuffed up again with the ("only one trigger source from ADC to DMA"). I think we were under the impression that we could assign a DMA trigger to each channel. But its the conversion group we are triggering from.

    Therefore our solution simply can't work.

    Thanks anyhow
    Stomp!.
  • 0 in reply to Jean-Marc Mifsud
    Genius 4675 points

    Hi Jean-Marc,

    So far we have managed to capture 3x ADC channels at max speed and stream the data over Ethernet to our data collection app.


    Limitations on the size of the DMA transfers are the next obstacle.

    Thanks for your help thus far!


    Cheers, Stomp!

  • 0 in reply to stomp
    TI__Mastermind 22375 points
    Stomp,

    What is the limitation you are facing? Can you elaborate?
  • 0 in reply to Jean-Marc Mifsud
    Genius 4675 points
    Hi Jean-Marc,

    Our scenario is:
    1. Capture 3x channels in 10bit resolution at 600ns/sample in the one group.
    2. Trigger a DMA request from the ADC at the completion of the group of samples.
    3. Use the DMA to transfer the 3x ADC samples (6 bytes) to our linear memory arrays such at we have u16Array[numChannels][numSamples].
    4. Capture about 100mS of data.
    5. At the end of the DMA block (nFrames x nElements) we get an interrupt to begin processing the data.

    With the current DMA implementation we are limited to frame and element counts/offsets of 0x1FFF bytes max.

    We configure our DMA control packet as such:
    1. Frame count = Num Samples (Max 8192 frames)
    2. Element Count = Num Channels
    3. Frame Dest Offset = 2Bytes
    4. Element Dest Offset = (num Samples * 2). <- This is the problem in that we can only have 8192/2 samples.

    To get around this problem we are experimenting with chaining multiple DMA channels together to perform the fill data capture as the hard limit for each DMA channel is the Element Destination Offset of 8192 bytes (4096 u16's).

    Thanks
    Stomp!.
  • 0 in reply to stomp
    TI__Mastermind 22375 points

    Stomp,

    The DMA chaining is not complicated, but depending on what you want to do there is some tricks to know.

    In each control packet, you have to specify which one is the next one. The value "0" means there is no chaining, "1" means channel 0 is the next, "2" means channel 1 is the next and so on.

    Control packet have to be configured as Hardware triggered.

    Lets say you are using Chan0, Chan1 and Chan2, and you want to execute all of them with single hardware trigger (ADC for example) and you want each trigger to repeat the sequence.
    Auto init on all 3 control packet have to be set.
    Now here is the trick. Because of the priority between each channel, with chan0 the highest if you chain 0->1->2, only 0 will start again and again on each trigger.
    So the correct chaining is 2->1->0 with the hardware trigger (from ADC) connected to chan2.

    In this scenario, Chan2 will start first and on completion will trigger Chan1. Because Chan1 is higher priority than Chan2 it will start and same for Chan0.

    Here is a test code that you can use as example.
    RTI_COMP0 is the trigger. Each channel 2 1 0 are moving data from 3 arrays to a gpio port.
    You will have to create a project to use this code.

    Please have a look and let me know if this is useful.

    6521.RM46_DMA_Chaining_GIO.zip

  • 0 in reply to Jean-Marc Mifsud
    Genius 4675 points
    Hi Jean-Marc,

    Again, thanks for taking the time to prepare the samples for us. Its helped a lot.

    One final question, do you know where in the datasheet / TRM we can find the value for the time between the completion of one ADC sample and the start of the next ADC sample in the same group?

    We have captured 3x channels of data and measured the total time between all samples at 4.16us. We have the ADC sample/hold set to 600ns, no capacitor discharge, ADC CLK = 25MHZ, VCLK = 100MHZ so there is 2.3us missing in our calculation somewhere.

    Any Advice?
    Thanks
    Stomp!
  • 0 in reply to stomp
    TI__Mastermind 49120 points

    Hi Stomp,

    I am assuming that you are using single-sequence mode for the conversions. There is a  6-VCLK cycle delay from hardware trigger to start of sampling of the first channel in the sequence. There are also 4 additional VCLK cycles between the end of conversion of one channel to the start of sampling of the next channel in the sequence. Here is a table of delays that we will include in the next update to the TRM:

    In your case, you would have the following delays:

    Delay from trigger to start of sampling of first channel = 6 VCLK periods = 60ns

    Sampling time = 600ns

    Conversion time (for 12-bit mode) = 13 * 40ns = 520ns

    Delay from end-of-conversion of first channel to start of sampling next channel = 4 VCLK periods = 40 ns

    This totals 1.22us for one conversion, so it still does not match the 4.16us you observe. How are you measuring this time for conversions?

    Regards,

    Sunil

  • 0 in reply to Sunil Oak
    Genius 4675 points
    Hi Sunil,

    Thanks!

    This is a lot more information that I could find in the data sheet. I did not factor in the conversion time, nor did I know it needed conversion time. I assumed the sample/hold was the conversion time.

    So what we have is:
    5 VCLK = 50ns (Software Start)
    +
    3 Channels, 560ns for sample/hold, 10 Bit mode (400ns), 40ns to to start of next conversion
    3 x ([560 + 400] + 40) = 3000ns

    Total time = 3050ns, 3.05us.

    My requirement is to sample 3x channels for 9600 samples at or above 80KHZ.
    A round trip time of 3.05us gives me 327khz sample rate.

    In rough numbers, ignoring the software start time each sample in memory should correspond to 1000ns of elapsed time. Can you confirm this is the case?

    Thanks again for your and Jean-Marc's support!

    Cheers
    Stomp!