• State
  • Locked Locked
  • Replies 6 replies
  • Subscribers 83 subscribers
  • Views 997 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

TMS320F28069UPZT Timing of simultaneous ADC sampling in NONOVERLAP mode

Mathias Felix
Prodigy 141 points

We are confused when comparing ADC timings from datasheet versus real measurements on the MCU. In real life the measuring takes longer than expected / calculated. This is not a problem as long as we know where the additional cycles come from.
It's important because we want to place the end of a particular SH phase to a well defined time (as usual in motor control applications). 

System configuration is as following:

  • SYSclock is 80MHz
  • ADCclock is 20MHz
  • NONOVERLAP mode is enabled
  • Simultaneous sampling is activated for SOC0 to SOC9
  • All channels use the same trigger which is ePWM2B
  • All channels have the same SH windows size of 6
  • The configurations of ADC channel, trigger selection and S-H window are written to the corresponding even SOCx numbers
  • All corresponding odd SOCx numbers are initialized with 0
  • All other unused SOCs are set to 0.
  • ADC interrupt 5 is enabled and configured to trigger CLA task 5 after EOC07 
  • ADC interrupt 6 is enabled and configured to trigger CLA task 6 after EOC09
  • Action qualifier registers are used inside CLA to toggle debug pins which are used to show occurrence of  a task

Now what we wanna do is to place the end of the S+H window of EOC8 / EOC9 to a defined time. To calculate the corresponding ePWM2B trigger value we use the following formula:

PWMcounts = (SH_01 + C0 + C1 + SH_23 + C2 + C3 + SH_45 + C4 + C5 + SH_67 + C6 + C7 + SH_89) * SYSclock / ADCclock   - or simplified to -

PWMcounts = (4 * (SH+ 2*C) + SH) * SYSclock / ADCclock   - now with numbers -

PWMcounts = (4 * ((6+1)+ 2*13) + (6+1)) * 80M / 20M = 556

When we measure the rising edges of the debug pins and compare them to a PWM reference signal, both CLA taks 5 and 6 are too late by approximately 300ns.  Delays for setting the pins are considered. Further the delay between task 6 and task 5 is closely to 1700ns which is equal to 34 ADC clocks. Subtracting the conversion time for both channels of 2 x 13 clocks a rest of 8 for SH remains.
According to the configured values for ACQPS = 6 and the technical reference we would expect here a value of 7 instead 8. Where does this offset come from?

Thank you in advance

Matt

  • 0
    TI__Guru 60865 points
    Hi Mathias,

    The minimum S+H window duration is 7 ADCCLKS, so I am assuming that you are using ACQPS = 6, which gives a S+H window of 7 ADCCLKs (and not ACQPS = 5, which gives S+H of 6 ADCCLKs).

    I think your calculations of timings are mostly correct. Some things to consider:
    *There is a delay from ePWM trigger to the S+H window of the first sample starting which is given as 2 ADCCLK cycles in figure 6-27 "Timing example for Simultaneous Mode...".
    *After the ADCINT flag is set, it takes the CPU some time to do a context switch to an ISR. This is about 14 cycles (processors.wiki.ti.com/.../Interrupt_FAQ_for_C2000). I am not sure what the latency is for CLA, but the CLA pipeline will need to fill up, so it will definitely be non-zero.
    *Your GPIO write instruction may be broken into multile CPU instructions. You can see these by looking at the disassembly. The CPU should execute 1 instruction per-cycle, unless there are data hazards that cause a pipeline stall (probably not in the case of trying to write a GPIO).

    So for the CPU, I get the following times:

    Minimum time from trigger to EOC7 CPU interrupt GPIO toggle (1 cycle for GPIO toggle):

    50ns * (2 + 4*7 + 13 * 6) + 12.5ns * (14 + 1) = 5587.5ns

    Minimum time from trigger to EOC9 CPU interrupt GPIO toggle (1 cycle for GPIO toggle):

    50ns * (2 + 5*7 + 13 * 8) + 12.5ns * (14 + 1) = 7237.5ns

    Delta = 7237.5ns - 5587.5ns = 1650ns

    So this is off by about 1 ADCCLK from what you observed (1700ns). I am not really sure how to explain this difference. Are you running from internal oscillator? The tolerance is about 3%, which could get you close (but I wouldn't expect to see this much error unless the device was operating near a temperature extreme): 1650ns * 1.03 = 1699.5ns. You could measure the ePWM frequency or XCLKOUT frequency to check.

    Devin
  • 0 in reply to Devin Cottier
    Prodigy 141 points
    Hi Devin,

    Thank you for your quick response and the clarification. We definitely forgot / overlooked the initial delay form ePWM trigger to SH window. This explains at least a part of the absolute offset but I'm wondering why we got still different values between two conversions.

    The clock is quite accurate, the tolerance is about 2 thousandth due to the ceramic resonator. I have verified this by measuring a PWM output signal which I use as reference for other measurements as well. The ACQPS is set to 6. In my first post I wrote that the SH window is 6 which was maybe a bit confusing.
    Since it's not possible to access GPIO's on the F2806x CLA we use action qualifier register to set and clear a certain output pin. Until now we didn't care much about the execution time of the pin management because our main focus was on the relation of the two tasks. As long as the delay is equal in both cases (tasks), it can be ignored. Nevertheless I have tried to measure it with the aid of my reference PWM output and I got values around 170ns.

    Your calculation of the minimum time is based on early interrupt scheme, right? It's possible that there's a difference of one cycle between early and late interrupt pulse?

    Mathias
  • 0 in reply to Mathias Felix
    TI__Guru 60865 points

    Hi Mathias,

    I did assume early interrupt mode.  In this case, the interrupt pulse occurs right after the S+H window is complete, before the conversion.  For late interrupt mode, the S+H window occurs after the conversion is completed, so 13 ADCCLKs later.  I think this is too much time to account for the overall latency. It is also a global setting for the ADC, so it shouldn't affect the relative timings of the two EOCs.

    We do provide timing diagrams in the DS for overlap mode (and unfortunately not for non-overlap mode).  Can you try (just as an experiment) to measure the timings in overlap mode?  If you don't match the DS timings here, we can focus more towards measurement method and ADC configurations.  If you do match, I can focus more towards getting confirmation from the design team on what the timings should be (it is possible my understanding is off by a cycle).  In either case, I will start the process of adding non-overlap timing information to the DS.

  • 0 in reply to Devin Cottier
    Prodigy 141 points
    Hi Devin,

    I have performed a couple more measurements and got the following perceptions:
    1. The mistake is always half a meter in front of the computer. See next:
    2. During the first runs I didn't realized that there's another task that bothers the measurements. After eliminating I got the expected values for the duration, at least between two consecutive conversions. With late interrupt pulse now I get 33 cycles in NONOVERLAP and 26 cycles in normal mode.
    3. The delay between PWM event trigger (compare) and the effective debug pin change (via CLA task) takes around 22 CPU cycles or 275ns.
    4. Taking into account the delay from 3.) a complete sample& hold and conversion cycle of two simultaneous measured values takes 37 cycles from the SOC trigger edge to the ECO pulse of the second conversion. This is in accordance with figure 8-35 of the reference manual.
  • 0 in reply to Mathias Felix
    Prodigy 141 points
    What I forgot in my last post is, that I'm still not understand completely what happens between two simultaneous measurements in NONOVERLAP mode. An addition to the corresponding chapters is very welcomed!
  • 0 in reply to Mathias Felix
    TI__Genius 13276 points

    Hi Mathias,

    Hopefully this picture helps.  The numbers represent ADCCLK cycles:

    Regards,

    Joe