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

TMS320F28377S: Problem using Differential mode ADC's with DriverLib

Iain Mosely
Prodigy 130 points
Part Number: TMS320F28377S


I am bringing up a new project using the 28377s Delfino which we have designed to make use of the differential mode ADC's (16-bit). The analog front end is tested and presents the IN+ and IN- signals differentially to the correct pins with the common-mode range in the required spec.

The problem I am facing is that when using the DriverLib functions to read back ADC values, the DriverLib provided ADC_readResult(ADCDRESULT_BASE, ADC_SOC_NUMBER0) function returns a uint16_t number. With differential mode signalling we should be receiving a signed integer number and simply casting the result as an int16_t doesn't fix this. IF we do cast it to int16-T and read out the data for a few operating points (including the gain of of our analog front end) we get the following relationship:-

There is a bit of noise etc but the linear relationship is about the right gain. The issue is that the ADC natively reports a value of about -32767 when the differential input is zero which is wrong. Is there another function in DriverLib which allows me to read the differential ADC output as a native int16_t?

Thanks,

Iain

  • 0
    TI__Guru 60865 points

    Hi Lain,

    If you have a look at the TRM sections for "Expected Conversion Results" and "Interpreting Conversion Results" you'll see that the differential ADC output is in the range 0 to 65535, with Vin+ = Vin- = Vincm (zero differential voltage) corresponding to 32768, so the native format is Unsigned 16-bit.  

    If you want zero differential voltage to correspond to '0' out, you can subtract 32768 from the results (being careful to cast as a 32-bit signed integer first).  Alternately, you can automatically make this calculation in the post-processing block (PPB) using the OFFREF field.  I think the driverlibs that return the PPB results should be 32-bit signed.  

  • 0
    Prodigy 130 points

    Awesome, thanks Devin, that makes sense now. I’ll use the PPB to add in this offset. 
    Thanks very much for taking the time to respond - very much appreciated.

  • 0 in reply to Iain Mosely
    TI__Guru 60865 points

    Sure, no problem!  Feel free to make a new post if you have additional questions or run into issues in your bringup that we can help with.