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.

TMS570 ADC sampling rate

Other Parts Discussed in Thread: HALCOGEN

Hi,

 

I am using the TM570 USB Development kit and I am having a problem setting the A/D sampling rate. Using HAL Code Generator I am enabling pin 0 of ADC 1 to sampling rate of 3.5us, in continuous mode. All other pins and ADC2 are disabled.

 

However, when I analysis the A/D results using a function generator input and FFT I come to the conclusion the sampling rate is 3.6393us, or about 4% longer than expected. Increasing the sample rate to 350us the % error is much less. So I suspect their are fixed number of clock cycles inbetween each A/D or it is being interrupted.

 

I’ve verified the crystal is 16 MHz, so the clock should be correct. Any other ideas? Are there a number of clock cycles the state machine must work through between each continuous conversion? Does DMA steal cycles from the ADC? Does the CCS debugger steal cycles from the ADC? Is there an independent method I can use to verify the actual A/D sample rate?

 

thanks

steve

HCK = 100MHz

VCL =HCLK/2 = 50Mhz

PS = 4

Cycle time = 100.0 ns (10 Mhz)

 

Discharge time = 0

Sample Prescaler = 20

Sample time = 2200 usec

Conversion time = 1.300 usec

Total Time = 3.5usec

  • Hi Steve,

    There are 4 VCLK cycles between the end of conversion of one channel and the start of conversion of the next channel within the same group. There are also other delays related to the ADC module design which will be included in the next datasheet release. I am attaching a document with these delays along with this email.

    3250.AWM_timings.docx

    As for the other questions in your message:

    • DMA does not interfere with the conversions in the ADC
    • A debug mode entry can halt the ADC conversions if the "Continue On Suspend" bit is not set

    Regards,

    Sunil

  • Hi Sunil,

    In the case where ADC channel 0 is converted continually - does this fall into the category of :

      a) channel to channel delay within same group

      b) channel to channel delay when group is changed

    Strictly speaking I would say a) by your document, but at the same time you're restarting at the beginning of the conversion group each time so could be b).

    Best Regards,

    Anthony

  • Sunil,

    Thank you, my VCLK=50Mhz or 20 ns, my programmed sample rate is 3.500 usec, the measured sample rate is 3.640 usecs, for a difference of 140ns or 7 VCLKS. Is it possible the 4 VLCKS is the channel to channel delay in one group, but their is an additional delay when the second group is checked for pending conversions (and finds none and starts over again in the first group)? Possibly that would account for the extra 3 VCLKS I am measuring in a single channel continuous conversion mode?

    Thanks

    steve

  • Steve,

    I have confirmed with the design team that the delay between two successive conversions is indeed 4 VCLK cycles.

    Regards,

    Sunil

  • Hi,  

    Can you tell me how you did to mesure the total ADC time,

    I am quite in the same configuration, but as I don't know how to mesure the adc conversion time

    I have a quadratic signal of 41-42 khz coming through my ADCgroup1 on pin0 and pin1, 

    I count the number of period for a sampling of 1024 values on 2 chanels = 47 periods

    my adc time total (by Halcogen 3.03) is 1.75 us (I guess for 2 convertions chanel 0 and chanel 1 in the same group) so  : 1.75 * 512  = 896 us for the 512 couples of values 

    Freq  = numberOf period / total sampling time  =  52 khz

    Is there someone to help me ?

     

  • Sunil,

    Since someone just commented on this thread I will give the solution we came up with concerning this problem. The only way we were able to get precise A/D conversions was to use the external trigger ADEVT, as soon as we did that all the timing problems when away. Otherwise, different builds with slight code changes caused the timing of the A/D conversion to change very slightly, which is probably acceptable for most people but not our application.

    steve

  • Brice Plavonil said:

    Hi,  

    Can you tell me how you did to mesure the total ADC time,

    I am quite in the same configuration, but as I don't know how to mesure the adc conversion time

    I injected an independent known precise sinewave into the A/D and analyzed the results (FFT/DFT etc).

    steve