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.

SM320F28335-EP: ADC simultaneous vs. sequential sampling

Part Number: SM320F28335-EP
Other Parts Discussed in Thread: C2000WARE

I need to sequentially sample all the sixteen analog inputs with the ADC. Therefore I've set the sequential sampling mode (SMODE_SEL=0) and the cascaded mode (SEQ_CASC=1).

Apart from that, I'm using the same configuration described in the first example in the table 1-7 of SPRU812A: SYSCLKOUT=150 MHz, HSPCP=3, ADCLKPS=0, CPS=0, ACQ_PS=0. In this configuration I'm expecting to get the conversion time of table 1-7 (12.5 MSPS or 80 ns) and therefore I'm expecting that for all of the sixteen channels, the whole conversion will take 80*16=1280 ns.

Instead, measuring the time between SOC (interrupt triggered by EPWM) and EOC (interrupt triggered by ADC), I get 1920 ns. Apparently each conversion takes three ADC clocks instead of two.

This is also confirmed by increasing ACQ_PS: each time the sampling takes one additional ADC clock:

ACQ_PS t calculated t measured
0 1280 1920
1 1920 2580
2 2560 3220

By reading SPRU812A, it seems that this behavior is correct for the simultaneous sampling mode (SMODE_SEL=1) where obviously two ADC clocks are needed in order to convert two channels (see Figure 1-3). But I'm in the sequential sampling mode, where just one ADC clock should be needed for the conversion (see Figure 1-2).

What am I doing wrong?

Thank you!

L.

  • Larry,

    Are you reading back the value of the EPWM from the ISR to determine the elapsed time?  If so, are you taking into account the TBCTL[HSPCLKDIV] setting?

    Can you see if the "adc_seq_ovd_test" example from C2000Ware produces the expected 8.3 MSPS sampling rate on your board?  This will help to check for any hardware issues.

    -Tommy

  • Hello Tommy, thank you for your answer. I'm measuring the elapsed time "experimentally": in the SOC ISR I set a general purpose I/O, and in the EOC ISR I reset it, so I can measure the pulse width directly on the scope. The measured times are very close to the theoretical values (apart from the additional ADC clock), therefore I believe that the measurement is correct.

    Perhaps SMODE_SEL=0, SEQ_CASC=1 is a configuration not valid? For some reason the example 1-2 in SPRU812A uses the simultaneous sampling even in cascaded sequencer mode (SMODE_SEL=1, SEQ_CASC=1). This is quite unclear to me: how can you both simultaneously sample two values, and cascade the two sequencers?

    Anyway I will also check the example from C2000Ware.

    Thank you!

    L.

  • Larry,

    The  SMODE_SEL=0, SEQ_CASC=1 combination is valid.  This will behave as if there is a single 16-position sequencer rather than two 8-position sequencers.  With SMODE_SEL=1, SEQ_CASC=1, the simultaneous conversion results are packed sequentially into the ADCRESULT registers.

    If you think that the times are consistent with simultaneous conversions, it would be a good idea to double-check the ADC configuration register values as read through the CCS Expressions window or Memory Browser.

    For your theoretical conversion times, don't forget to include the first-sample overhead:

    -Tommy

  • Hello Tommy,

    You are right, I didn't take into account the extra cycles! In total there should be 7.5 additional ADC clock cycles to consider: 2.5 at the start, 3 for the first sample (4 cycles instead of 1) and 2 at the end due to the delay on the update of the last ADCRESULT register. With this cycles added, the previous times become:

    ACQ_PS t calculated t measured
    0 1580 1920
    1 2220 2580
    2 2860 3220

    In this way the measured times get closer to the theoretical times. There still is a fixed additional delay of around 360 ns, but now I'm quite convinced that the ADC is configured correctly and this delay is due to something else. In particular, in the EOS interrupt before clearing the general purpose I/O there is some (supposedly) short code for IER update and PIE interrupt acknowledging. Perhaps this is the origin of the delay, we will investigate

    In the meanwhile, thank you!

    L.