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.

28075 Control Card: Bad ADC performance - only 7 bits valid?

Other Parts Discussed in Thread: CONTROLSUITE, OPA4376, TMDSCNCD28379D, OPA4322, OPA320, OPA4350, OPA350

Hi,

I found great noise in the ADC values of the F28057 control card with the 180 to 100 adapter and our own test hardware. I tried several things to reduce it (different signal sources, different reference voltages, emulator connections, power supplies, adc acquistion window sizes etc.), but did not succeed.

Finally, I reduced it to the following easyly reproducable experiment: I used a 1.5V alcali cell as a low effort, low noise, and low impedance voltage source and measured its voltage both with the 28069 and the 28075 control card using the software provided by TI in the control suite:

C:\ti\controlSUITE\device_support\f2806x\v151\F2806x_examples_ccsv5\adc_soc\Example_2806xADcSoc

C:\ti\controlSUITE\device_support\F2807x\v190\F2807x_examples_Cpu1\adc_soc_continuous\cpu01\adc_soc_continuous_cpu01

Here is a plot of the results:

The 28069 board on the 100 pin docking station shows not overwhelming, but acceptable performance (noise <=10 increments at ADC A4 to GND), but the 28075 on the 120/180 docking station is by factor 6 worse (about 60 increments noise at ANA 09 to GND J10)! Both measurements ran under the same conditions (power supply, emulator, environment).

Any similar or different experiences, any explanation?

Thanks,

Frank

  • Hi Frank,

    I would suggest using the 3.0V reference. The DS requires VREFHI <= VDDA at all times, so you could theoretically run into issues if VDDA is also nominally 3.3V but drifts to something a little lower. Practically this isn't usually a problem, but 3.0V would be the better choice (I think the next revision of this kit will have 3.0V and VDDA as the VREFHI options).

    As far as the codespread, some debug experiments that you can try:

    -Measure the 3.0V reference pin with a multi-meter. This should be very close to 3.00V. An appreciable error could indicate some issue with the reference IC or op-amp driver.
    -Try one of the other ADC example programs. adc_soc_epwm would probably be a good choice.
    -Add a small input capacitor (10pF)to the channel you are sampling. On the CCard, the footprints for these are C18 - C37 (you can get the schematic in ControlSUITE, .\development_kits\~controlCARDs\TMDSCNCD28075_v1_2\R1_1\).
    -Same as above, but use a large capacitor that is at least Ch (16.5pF) * 4096 * 4. This will give you something around 270nF. Note that in this case, you will probably need to slow down the sample rate, so the adc_soc_epwm example would be the way to go.

    Some other sanity checks:
    -Enable XCLKOUT and measure the (divided down) SYSCLK. Ensure that the SYSCLK speed is as expected by the SW.
    -After the ADC initialization run in the SW, set a break point and then manually examine the ADC configuration registers. Of particular interest would be the ADC prescale setting and the ACQPS setting(s) in the SOC configuration(s).
  • Hi Devin,

    thank you for your reply and sorry for my delayed response due to my vacation from office for 3 weeks.

    According to your hints I did a couple of measurements, here are the main results:

    First I used the 3.0 V reference (changed SW2.1, SW2.2 on the control card in left position):
      The mean value of the conversion results changes from 18xx to 20xx ass expected, but still with bad accuracy.

    - The 3.0 V reference was measured to be 2.992 V (not calibrated multimeter),
      3.3 V reference is 3.29 V, both measured on SW2 to GND.
     
    - Scope measurements also look good on SW2 (U12 OPA4376 inputs). But on the U12 outputs (pins 1, 7, 8) I measured an oszillation of about 60 mV and 120 kHz, large enough to explain the measured adc inaccuracy:
     60 mV / 3.0 V * 4096 inc = 81.92 inc.
     
    I consulted the OP amp data sheet:
     
    www.ti.com/.../opa4376.pdf, p. 14 ff.
    Chapter 7.3.3 Capacitive Load and Stability
     
    The OPAx376 in a unity-gain configuration can directly drive up to 250 pF of pure capacitive load.

    Your designers applied a C15 = 2.2 uF - a little bit less than by factor 10.000 larger, see the schematics
    C:\ti\controlSUITE\development_kits\~controlCARDs\TMDSCNCD28075_v1_2\R1_1\F2807x_120controlCARD_R1_1_SCH_05Aug2014.pdf

    There is also a warning in the TMDSCNCD28075_Infosheet_v1_2.pdf:

    2.2 Warnings about Specific controlCARD revisions –
    Warnings about R1.1 and earlier controlCARDs:
    1. The circuitry used to drive the C2000 MCU’s voltage references on the controlCARD is not ideal.

    A nice euphemism.

    I replaced the 2u2 C15 with a 100p value and obtained a stable reference voltage VREFHIA unless there is no conversion in progress, the VREFHI is tied down with the conversions.
    The adc converted values look better, but now show a strange distribution, see the plot. There seems to be preferences of values near 2023, 2038, 2054, 2070 - a distance of 16 between the values.

    Then I replaced C15 = 2u2 and R44 = 2R2 to get something similar to the change suggested in F2837xD_VREFHI_12bitDrivingCkt.pdf, again with little improvements.

    Finally I tried the suggested Caps (10 pf, 100 nF) at the ADCINAx inputs. Only with the large 100 nF I get less than 10 increments noise.

    ADC settings are    

    /* 120 MHz / 3 = 40 MHz, set ADCCLK divider to /3 (PRESCALE = 4) */
    AdcaRegs.ADCCTL2.bit.PRESCALE = 4;  // also tried 6

     AdcaRegs.ADCSOC0CTL.bit.ACQPS = 14; // up to 60, little effect on adc noise, but absolute value changes with low ACQPS values.

    SYSCLOCK is correct.

    Conclusion: The ADC not only needs to be carefully driven at its inputs, but also on its reference voltages.

    Here is a plot of the measurements.

    Will need some further work to find the right dynamic settings. Thanks.

    Frank

  • Hi Frank,

    First of all, I apologize for the issues you've run into.  As you've seen, we've attempted to partially rectify the situation by adding an appropriate voltage reference circuit and notes about the problems with the controlCARD in the infosheet document.

    We do have a need to revise this controlCARD so that some of the errata items in the infosheet are resolved (like this), but there is not a plan in the short-term to do this.

    ===

    The OPA4376 is really not a good choice for driving the ADC references on the C2000. 

    A significant improvement could be made by using the circuitry specified in the F2837xD_VREFHI_12bitDrivingCkt.pdf file or via the circuitry included in the most recent, TMDSCNCD28379D.  The problem is that these cannot easily be put on to the existing F28075 controlCARD. 

    An option that should improve the VREF driving capability significantly (with the existing F2807x cCARD) is to replace the OPA4376 with a OPA4322, which is pin-to-pin compatible with the OPA4376 in the PW package (14-TSSOP).  Note that the OPA*322 and OPA*320 have very similar driving capacitive driving capabilities and therefore the driving circuit for the OPA*320 will be the same as what you'd use if you used a OPA*322.  However, the OPA*322 has a bit worse Vos specifications and, as a result, it will perform a bit worse than the OPA*320.

    Still, changing to the OPA4322 should give significant improvements to the driving circuit.

    Note that we have done in-house testing with the OPA320 driving circuit and have seen good results with it.

    Hopefully this helps!


    Thank you,
    Brett

  • Brett,

    thank you for the information. We will use the suggestions when we will design our own board.

    BTW, I also measured the ADC of the (old) 28377D R1.1 control card. It uses the same circuitry as the 28075 board, but with a LPM7709 OPA, also not really good performance (50 increments noise with 3.3V reference).

    The 28379 R1.3 board uses a OPA4350 / 100m / 22uF combination compared to the OPA320 / 560m / 2u2 in F2837xD_VREFHI_12bitDrivingCkt.pdf. Which to you think is better?

    It will also take some effort to design the ADC input circuits, the 100 nF cap I used in my experiments to achieve low noise will definitely be too big to meet the requirements on the dynamic of our application. Do you have some advice for OPAs for shunt current measurement for a > 100 kHz PWM motor control?

    Thanks

    Frank
  • Hi Frank,

    The OPA*350 driving circuitry is the 'better' driver and has been designed so that the C2000 ADC will give good 16-bit conversion results.
    The OPA*320 driving circuitry is a bit of a step-down from the OPA*350, but is more than adequate to give very good results when the ADCs are used in 12-bit mode. 

    Note that the OPA*320 driving circuit will be cheaper than the OPA*350 driving circuit.

    ===

    When shunt leg sensing, my first instinct is to use the OPA*350 opamps - usually with some gain resistors around it to amplify the input signal.  These are great opamps.  My team uses these opamps heavily in our system evaluation kits (whether in motor control or electrical power conversion applications).

    Please note the ADC's internal input model (sampling capacitor, etc) is provided in the datasheet to help enable simulations to be done by the system designer so that they can design good input driving circuitry (and help define the appropriate sampling window that the ADC should be configured to use).


    Thank you,
    Brett

  • Hi Frank,

    A couple points on the tradeoff between OPA320 vs. OPA350:

    *OPA350 has slightly lower noise and higher bandwidth, but higher Vos This comes in a 4x package.
    *OPA320 has slightly higher noise and lower bandwidth, but lower Vos. It is also slightly cheaper per channel.

    Since F2807x devices only has 12-bit ADCs, I think you will want to go with OPA320 (+2.2uF and 560m ohm). Also note that we have characterized performance with one OPA channel driving two VREFHI pins and this works well - you should be able to meet DS performance in this case.

    As far as the design of the input circuitry, you can go one of two ways. One way is to go with a large capacitance and a lower sample rate (this will give you an analog LP filter). Alternately, you can use a small capacitance on the pin, which won't give you much analog LP filtering, but you can sample at a rate up to the maximum supported (and you can use these extra samples do SW filtering if needed). I discussed this in more detail in this recent post: e2e.ti.com/.../534361
  • Hi Brett, hi Devin,

    thank you both for the informations that are very helpful for the design of our board. I'll be back if new questions or problems arise...

    Bye,

    Frank