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.

TMS320F28377S: Question about DAC output voltage variation

Part Number: TMS320F28377S
Other Parts Discussed in Thread: REF3130, TMS320F28379D, CONTROLSUITE, C2000WARE

Dear All,

We are working on TMS320F28377S. We are using DAC - B to set output current limit of external module.

We are using TI's REF3130 reference voltage source. We observed the reference voltage as 2.0085V

As per datasheet the DAC output expected within +/-5 LSB range.

While testing we observed the DAC output has variation 9 to 16 LSB (Refer base board DAC B)

To analyze the observation, we validate the result with other DAC channel and with TMS320F28379D evaluation board.

As shown below with DAC A on our developed board, we found the variation within expected 5 LSB (Refer base board DAC A)

With TMS320F28379D evaluation board,

  • For DAC A variation observed 0 to 8 LSB
  • For DAC B variation observed 1 to 12 LSB

We used sample code for testing from bellow link for testing. 

C:\ti\controlSUITE\device_support\F2807x\v210\F2807x_examples_Cpu1\buffdac_enable\cpu01\ccs

Just changed REFERENCE and ADC channel as below . Attached is the code used for testing.

#define REFERENCE REFERENCE_VREF

#define DAC_NUM DACA

buffdac_enable.zip

Our queries:

On our board, we observed good result for DAC A (within expected +/- 5 LSB variation) against DAC B. On evaluation board, we observed good result for DAC A against DAC B.

On our board, for 0 count input to DAC B, we observed offset of 0.0136V.

1) What might be the possible reason for DAC A gives good result against DAC B?

2) On our board, how we can get DAC B output within expected +/- 5 LSB variation?

3) On our board for DAC B, how we can can overcome offset of 0.0136V for 0 count setting? What is the reason for this high offset ?

Regards...

Yogesh 

  • Hello Yogesh,

    I am taking a look at your question. I will respond by Monday.

  • Hi Yogesh,

    We are using TI's REF3130 reference voltage source. We observed the reference voltage as 2.0085V

    Can you clarify what is the reference voltage? Note that per DS, reference voltage needs to be between 2.4V and VDDA.

    As per datasheet the DAC output expected within +/-5 LSB range.

    The +/-5 LSB spec is only for INL, this is not the final output error. The output error depends on offset error, gain error, and INL (reference: https://e2e.ti.com/blogs_/b/analogwire/posts/dac-essentials-how-accurate-is-your-dac).

    Note that the offset error is adjusted at midcode (2048) on each device for internal reference. Since you are using external reference, you will need to re-adjust it. You can use the C2000ware function DAC_tuneOffsetTrim() to adjust the offset error (more information on "DAC Offset Adjustment" is given in the device technical reference manual).

    3) On our board for DAC B, how we can can overcome offset of 0.0136V for 0 count setting? What is the reason for this high offset ?

    The DAC has an output voltage range defined as 0.3 to VDDA-0.3. The 0 count setting is outside this linear operating range. 

  • Hi Martinez,

    Thanks for your reply.

    Our measured reference voltage is 2.9985 V. There was typo mistake.

    Basis your feedback we adjust the offset using DAC_tuneOffsetTrim()  function. The offset trim value changed from 19 to 15. 

    But we still observed variation in DAC output above 5 LSB for 2048 count.

    Then we tried one more method, where

    • first reset offset trim using DAC_setOffsetTrim(0x5C10, 0).
    • Then we  measured DAC output LSB difference at 2048 count. We found same as 13
    • Then we set the offset trim using DAC_setOffsetTrim(0x5C10, 13)
    • This time we observed variation in DAC output below 1 LSB for 2048 count
    • For complete span DAC output for 0.01 to 3 v, we observed DAC output below 5 LSB 

    We will repeat the experiment which we did DAC_tuneOffsetTrim(). We are sure this method should also work. There might be some mistake in our execution.

    One observation,

    • For both DAC_tuneOffsetTrim(), DAC_setOffsetTrim() we confirmed the offset trim using DAC_getOffsetTrim. We found expected value.
    • After power cycle, when we tried to confirm the offset trim using DAC_getOffsetTrim. We found the old value before execution of DAC_tuneOffsetTrim(), DAC_setOffsetTrim().
    • What might be the reason for offset trim value not getting updated to new value.

    Regards.....

    Yogesh

  • Yogesh,

    Basis your feedback we adjust the offset using DAC_tuneOffsetTrim()  function. The offset trim value changed from 19 to 15. 

    Can you share the exact code you used with the DAC_tuneOffsetTrim() function?

    After power cycle, when we tried to confirm the offset trim using DAC_getOffsetTrim. We found the old value before execution

    This is expected. See the post below.

    https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/928778/tms320f28377d-dac_tuneoffsettrim

  • Hi Marthinez,

    After using DAC_tuneOffsetTrim, we are now getting good result with DAC.

    So we understood the DAC used to have factory calibrated Offset trim @ 2.5 reference voltage. We are using reference voltage as 3.00, so it is necessary to change this factory calibrated Offset trim.

    For ADC also we are using same reference voltage as 3.00. So does similar offset trim also applicable ADC or not?

    Regards....

    Yogesh

     

  • Yogesh,

    We should get a reply back to you tomorrow on the ADC aspect, need to pull in another engineer who owns this IP to the thread.  Appreciate your patience.

    Best,

    Matthew

  • For ADC also we are using same reference voltage as 3.00. So does similar offset trim also applicable ADC or not?

    Based on design expectations, the factory trim for ADC should suffice for different reference voltages. There is an optional offset retrim procedure that is documented, but this is typically not done.