• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 82 subscribers
  • Views 975 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.

TMS320F28377D: How to implement ADC sampling synchronously on both cores without overlap S+H and conversion time between different ADC modules

Sheldon He
Expert 8585 points

Part Number: TMS320F28377D

Hi expert,

My customer is using F28377DPTPT on their current product. They doing ADC sample on both CPU1 and CPU2 (12bits single ended). On CPU1, they sampling at 16kHz and 32kHz with multiple trigger source. On CPU2, they sampling around 16kHz (shift around this point) with single trigger source.

They are not being able to do synchronous sampling like mentioned in TRM. So my questions are:

Q1: If there are any method to do synchronous sampling in this case?

Q2: What is the worst case would be on ADC performance in this case?

Q3: Will the picture below show the worst case?

Thanks

  • 0
    TI__Guru 60865 points

    Hi Sheldon,

    The samples will end up synchronous as long as each trigger source simultaneously triggers a full set of SOCs.

    e.g. 16KHz CPU1 triggers all ADCs SOC0 and SOC1, 32KHz CPU2 triggers all ADCs SOC2 and CPU2 ~16kHz trigger triggers all ADCs SOC3 and SOC4.  

    You would need to add dummy SOCs if you don't need conversions from all ADCs for each trigger. 

    This will, however, result in some jitter in the trigger-to-sample time because the ADC may or may not be busy when any particular sample comes in. 

    The change in the DC value of the ADC results will be worst case.  The degradation in ENOB is specified as a typical, but should give you a better idea of the effective average performance when operating asynchronously. 

    It is worth noting that the ZWT package has much better performance for an asynchronous use case.   

  • 0 in reply to Devin Cottier
    TI__Expert 8585 points
    Hi Devin,

    Thanks for your detailed answer. Some related points to check with you:
    How could I correctly understanding "ADC to ADC isolation" in the datasheet?
    Will 2.5V and 3V reference give different ENOB performance when other variables are the same? If yes, do you have a recommended external reference voltage?

    Sheldon
  • 0 in reply to Sheldon He
    TI__Guru 60865 points
    Hi Sheldon,

    ADC-to-ADC isolation is the change in average conversion result on one ADC based on operation of the other ADC(s). Say ADC-A, operating alone, outputs an average code of 3423 for some given DC input voltage. With the worst case aggressor ADC(s) and at the worst case relative timings between the multiple ADCs and with the worst case voltage on the aggressor ADC, the average conversion on ADC-A could read back 3423 + Isolation Spec' on average.

    Usually when you operate the ADCs asynchronously, you only rarely run into the worst case relative timing and voltage conditions, so the above specification is rather conservative.

    Sine the ADC has some inherent noise that doesn't scale with VREFHI, higher VREFHI will typically give slightly better SNR performance. Assuming SNR is the limiting factor for determining ENOB (it typically is for C2000 ADCs), increasing the VREFHI will increase SNR which will then increase ENOB. We specify ENOB at 2.5V, which should be roughly worst case. If you went from 2.5V to 3.3V, SNR could increase by at most 20*log(3.3/2.5) = 2.4dB.

    We'd usually recommend VREFHI of 2.5V or 3.0V because those voltages have readily available reference ICs. 3.3V is possible, but VREFHI < VDDA needs to be strictly followed, so you would need to artificially push up the VDDA and VDDIO supply voltages above 3.3V, but below the maximum operating voltage, which is usually not very practical.