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

TMS320F280049C: Confusing example design regarding ADC offset trim value update

Lennart Gardian2
Intellectual 270 points
Part Number: TMS320F280049C


Hi there,

I'm currently taking a look into the adc_ex4_soc_software_sync example from the C2000 ware 3_04.
What confuses me is that the ADC_setVref function updates the offset trim value for the ADC. It does so by taking the according value from the OTP flash and copy it to the active offset trim register at ADC_BASE_ADDRESS + 0x3B.

What confuses me is that it is done manually while the TRM states the usage of the Device_cal() function. I then figured out that the Device_cal() function actually is used prior to the ADC_setVref function but the results are different. For my paticular device the offset trim value behaves as follows when running the Launchpad in debug mode

Startup

adc offset trim reg = 0 // as expected

Device_init(); // including Device_cal() function

adc offset trim reg =240

ADC_setVref(...)

adc offset trim reg =224

I now wonder which one is the right value and why ADC_setVref is copying the value again. Is there some known issue with Device_cal() Could you tell me the address for the ADCA's offset trim value in the OTP memory? I coudn't find it in the TRM and hence having trouble to verify the addresses used in ADC_setVref.

Any help would be highly appreciated.

Thanks,

Lennart

  • 0
    TI__Guru 60865 points

    Hi Lennart,

    I believe that setVref is actually loading a slightly different offset trim depending on whether the device is in external reference mode or internal reference 2.5V mode or internal reference 3.3V mode.  This is a performance tweak to give slightly better performance on average. 

    In any case, since the unit of the offset trim is 1/16th of an LSB, the difference between your two trims is only 1 LSBs, so it shouldn't cause too much concern either way.  

  • 0 in reply to Devin Cottier
    Intellectual 270 points

    Hi Devin,

    yeah that might actually be the case. The device_cal() probably loads the calibration for 2.5V internal ref? At the point of device_cal() it is all on default and so it might just no now about it?

    Could you tell where exactly all those calibration values so I can make sure that I pick the right one? Can't find it in the TRM.

    Thanks for the quick reply!

  • +1
    TI__Guru 60865 points

    Hi Lennart,

    I don't think we document the specific contents of the TI OTP.

    The best way to load the correct trim is to use the driverlib functions since these will take care of it for you.

    If you want to write your own code to do this I think you'll have to reverse engineer the locations from the driverlib:

        //
    // Offset trim for internal VREF 3.3V is unique and stored in upper byte.
    //
    if((refMode == ADC_REFERENCE_INTERNAL) &&
       (refVoltage == ADC_REFERENCE_3_3V))
    {
        offsetShiftVal = 8U;
    }
    else
    {
        offsetShiftVal = 0U;
    }

    //
    // Set up pointer to offset trim in OTP.
    //
    offset = (uint16_t *)(ADC_OFFSET_TRIM_OTP + ((uint32_t)6U *
                                                 (uint32_t)moduleShiftVal));

    //
    // Get offset trim from OTP and write it to the register.
    //
    EALLOW;
    HWREGH(base + ADC_O_OFFTRIM) = (*offset >> offsetShiftVal) & 0xFFU;