• State Resolved
  • Locked Locked
  • Replies 10 replies
  • Answers 1 answer
  • Subscribers 82 subscribers
  • Views 245 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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-EP: Internal DSP ADC trim (offset and linearity)

Laurent Z.
Intellectual 285 points
Part Number: TMS320F28377D-EP
Other Parts Discussed in Thread: C2000WARE

Hello,

Regarding the ADC trims that need to be loaded every time the ADC mode and resolution changes, per the errata, I have three questions:

  • Why for a 12bit resolution, the upper 16bits of INLTRIM1,2,4,5 are kept and the lower 16 bits are set to zero?
  • Why INLTRIM3 and INLTRIM6 are kept the same?

Could someone explain to me a little bit more in details the way this work. The industry in which my application is used, require me to have a clear understand on the way it works for safety reasons.

  • What does module reset mean in the following sentence from the TRM? If there is a DSP reset aren't the boot ROM repopulating the ADC trims registers?

Thank you.

Laurent

  • 0
    Intellectual 285 points

    Also, Why in the Boot_ROM file c1_bootrom.h the DEVICE_CAL_LOCATION point to the address 0x070280

    But the TRM and the source code point to the address 0x070282

    Laurent

  • 0 in reply to Laurent Z.
    Intellectual 285 points

    One more thing, while using the JTAG debugger, I am calling Device_Cal() function since the Boot Rom is not executed and the Gel script does not implement the function:

    I noticed that the ADC registers are not populated.

    However, if I execute AdcSetMode() function, the ADC registers are populated.

    Can we really trust this Device_Cal() function for doing is job during Boot ROM and in the source code!?

    Laurent

  • 0
    TI__Expert 7436 points
    Laurent Z. said:
    • Why for a 12bit resolution, the upper 16bits of INLTRIM1,2,4,5 are kept and the lower 16 bits are set to zero?
    • Why INLTRIM3 and INLTRIM6 are kept the same?

    The linearity trim bits required for 12bit mode are different (and much fewer) than the bits required for 16bit mode. This is directly related to the internal design and which conversion caps are used. We cannot share the details of this ADC design publicly as it is TI IP. The zero/unused bits do not impact operation of the ADC in 12bit mode.

    Laurent Z. said:
    What does module reset mean in the following sentence from the TRM? If there is a DSP reset aren't the boot ROM repopulating the ADC trims registers?

    It is possible to individually reset a peripheral without rebooting the entire MCU by writing to the corresponding SOFTPRESx register in the system control module. (For the ADC modules, this is SOFTPRES13.) 

    Laurent Z. said:

    Also, Why in the Boot_ROM file c1_bootrom.h the DEVICE_CAL_LOCATION point to the address 0x070280

    But the TRM and the source code point to the address 0x070282

    The first address (0x70280) is an entry vector to the function at 0x70282. The C2000Ware code is correct and validated.

    Laurent Z. said:

    One more thing, while using the JTAG debugger, I am calling Device_Cal() function since the Boot Rom is not executed and the Gel script does not implement the function:

    I noticed that the ADC registers are not populated.

    However, if I execute AdcSetMode() function, the ADC registers are populated.

    Can we really trust this Device_Cal() function for doing is job during Boot ROM and in the source code!?

    The GEL script is not the same as the boot ROM function. I will follow up to see if this GEL script can be fixed/updated in an upcoming CCS release as part of the F2837xD device support. But that has no impact on the boot ROM or the operation of the device itself - this is just a convenience debugger script that is intended to ease debug.

    The device boot ROM is fully validated and does populate ADC registers during boot as expected.

    Best regards,
    Ibukun

  • 0 in reply to Ibukun Olumuyiwa
    Intellectual 285 points

    Ibukun, thank you very much for answering my questions, it is very helpful.

    I would like to go back to my last concern regarding Device_Cal() though.

    Do you have any clue why when I call Device_Cal() from my source code it doesn't populate the ADC register but calling AdcSetMode (which contain CalAdcINL() and GetAdcOffsetTrimOTP) does? see image below. There might be something I don't understand. 

    Device_Cal():

    AdcSetMode()

    Thank you

    Laurent

  • 0 in reply to Laurent Z.
    TI__Expert 7436 points

    Yes, that post has the right answer. There are a number of different trims required for ADC and other analog circuits to function correctly. The INL trim is dependent on what resolution has been configured, and so it will not be populated until the AdcSetMode() function has been called. But some of the other fundamental trims are populated using device cal; these specific trims are not exposed as user accessible registers.

  • 0 in reply to Ibukun Olumuyiwa
    Intellectual 285 points

    Okay, makes sense, the errata made me confused. I thought it was done during Boot ROM. It seems that the Note statement might be wrong or misleading.

  • 0 in reply to Laurent Z.
    Intellectual 285 points

    Any comments on those two statements?

    • "The INL trim is dependent on what resolution has been configured, and so it will not be populated until the AdcSetMode()"
      • VS
    • "Note that on start-up, trims will be loaded for 12-bit, single-ended operation (errata SPRZ412L)"

    Laurent

  • 0 in reply to Laurent Z.
    TI__Expert 7436 points

    Laurent,

    I looked into this a little bit more and the statement in the errata is not quite accurate. This will be fixed in the next release. There are internal ADC trims that are loaded at start-up, but the resolution- and signal mode-dependent trims are only loaded when AdcSetMode() is called.

    Best regards,
    Ibukun

  • 0 in reply to Ibukun Olumuyiwa
    Intellectual 285 points

    Ibukun,

    Perfect, thank you so much for your help, I really appreciate it.

    Laurent