• State
  • Locked Locked
  • Replies 7 replies
  • Subscribers 32 subscribers
  • Views 233 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.

MSPM0G3519: Regarding ADC conversion

Bhavpreeta Charan
Expert 4390 points

Part Number: MSPM0G3519

Hello experts,

If ADC Clock Source is set to ULPCLK, SYSOSC trimmed to 16MHz, and tied to ULPCLK, the A/D conversion value will return 0. 

When HFCLK is set to HFXT (16MHz) and connected to ULPCLK, the A/D conversion value will return the desired value.

Both setup are running on RUN0 and other than the difference that ULPCLK is connected from HFXT or SYSOSC, there are no other changes.

Is there a configuration that I am missing? Why is this issue occuring?

  • 0
    TI__Expert 6615 points

    Hi, can you try the following:

    1. Double check the trimmed output for correct frequency for the sysosc case
    2. Disable the 16MHz trim on sysosc and repeat the test to see if the issue persists
    3. Just to cross these off the list:
      1. try to increase the SCOMP setting to give the input signal time to settle and see if the issue persists.
      2. Try reducing the SCLKDIV to lower the sampling clock frequency and check for the issue

    Let me know if these result in the same behavior and we can narrow down the root cause of the issue from there.

    -Brian

  • 0 in reply to Brian Dempsey
    TI__Expert 4390 points

    Hey Brian,

    Brian Dempsey said:
    Double check the trimmed output for correct frequency for the sysosc case

    16.08MHz

    Brian Dempsey said:
    try to increase the SCOMP setting to give the input signal time to settle and see if the issue persists.

    Customer tried to do it but they didn't observe any change, even when SCOMP value is maximum.

    Brian Dempsey said:
    Try reducing the SCLKDIV to lower the sampling clock frequency and check for the issue

    Set SCLKDIV to 0, then 1, then 2, then3, but didn't observe any change.

    --

    Still checking on number 2

  • 0 in reply to Bhavpreeta Charan
    TI__Expert 4390 points

    Hey Brian,

    Brian Dempsey said:
    Double check the trimmed output for correct frequency for the sysosc case

    Customer adjusted SYSOSC to 16.01MHz setting, but the a/D conversion failed.

    Brian Dempsey said:
    Disable the 16MHz trim on sysosc and repeat the test to see if the issue persists

    Customer set the ADC setting to SYSOSC and set SYSOSC back to 32MHz, but the a/D conversion failed.

    Brian Dempsey said:
    Just to cross these off the list:
    1. try to increase the SCOMP setting to give the input signal time to settle and see if the issue persists.
    2. Try reducing the SCLKDIV to lower the sampling clock frequency and check for the issue


    3-(1) AD conversion could not be performed even if it was set to MAX.
    3- (2) the current setting is divide by 1, so I tried divide by 2, 4, and 8, but I could not convert to a/D conversion.

    --

    Also do you think this issue could be related to following errata?


    I think the position where the AD conversion result is stored is misaligned.
    It is similar to ADC_ERR_10 in errata, but the situation is different, so please check it.

    Setting:

    Pins

    PA15 I2C1_SCL
    PA18 BSL invoke
    PA21 ADC
    PA22 Not assigned

    ADC CLOCK : ULP

    Software is same for following two observation, only clock is different.

    The red frame is the part where you want to perform AD conversion this time
    When HFXT is used, it is generated in the place as intended, but the AD conversion was obtained.
    When performed with SYSOSC, the result is stored in an unintended place, and the place to read is 0.

    (In case of sysosc is 16.0878, only converting ADC0[4] and ADC1[5])

  • 0 in reply to Bhavpreeta Charan
    TI__Expert 4390 points

    Hey Brian, Any update here?

  • 0 in reply to Bhavpreeta Charan
    TI__Expert 4390 points

    Hello Brian,

    Haven't hard back from you on this thread. Could you please support it?

  • 0 in reply to Bhavpreeta Charan
    TI__Expert 4390 points

    Hey Brian,

    Could you please support this query?

  • 0 in reply to Bhavpreeta Charan
    TI__Expert 6615 points

    Hi Bhavpreeta, yes this could possibly be related to the errata you showed since the I2C can be toggling during a transaction on PA15. If the clock is the only variable changing during testing, I would suspect the sysosc sourcing the ADC is the issue. Can we take this offline via email?

    -Brian