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

AM2434: AM24x ADC0 Measurement at AIN7

Robert Czech
Prodigy 170 points
Part Number: AM2434

Tool/software:

We run a setup with an Sitara AM2434 (ALV) and want to measure low signals. We use AIN4 to AIN7, AIN4 and 5 work fine with no offset, but AIN6 has a little offset and AIN7 an offset of about 15mV by 1.8V reference.

We disconnected the real signal source and just left a 820 Ohm resistor attached from the AIN7 to GND. With this setup the offset still exists. After we shorted the resistor, the ADC really measured 0mV.

We measured the same behaviour for multiple devices. Is it possible that the AIN7 (and AIN6) has a higher leakage current than the other ADC inputs by design? Will it make sense to change the PCB design to use another AIN for the measurement of low signals?

  • 0
    TI__Guru**** 188899 points

    Hello Robert Czech,

    Thank you for the query.

    Can you confirm if this is a custom board.

    Robert Czech said:
    We disconnected the real signal source and just left a 820 Ohm resistor attached from the AIN7 to GND. With this setup the offset still exists. After we shorted the resistor, the ADC really measured 0mV.

    The input leakage should be less than 10uA.  So they should not be measuring 15mv when connecting the input to VSS via a 820 ohm resistor.  The most they should measure would be V = I * R = 10uA * 820 ohms = 8.2mV, when we assume the worst case input leakage of 10uA is flowing through the 820 ohm resistor.

    Does the offset increase if the 820R is increased to 1.5K or 2K.

    Here are some thoughts 

    I suspect this is being caused by something else.  Can you confirm the ADC clock rate.  The ADC should be operating at 60MHz.

    How are the VDDA_ADC0, ADC0_VREFN, and ADC0_VREFP pins connected?

    Are you able to share the schematics for a quick check.

    Regards,

    Sreenivasa

  • 0 in reply to Kallikuppa Sreenivasa
    Prodigy 170 points

    Hello Kallikuppa Sreenivase,

    I checked the clock source for the ADC0 and indeed it was still connected to HFOSC0_CLKOUT which is 25Mhz (like the register default). I added code to set it to MAIN_PLL1_HSDIV6_CLKOUT. 

    /* Set ADC clock source to PLL1_HSDIV6 */
        static const uint32_t CLK_SOURCE_PLL1_HSDIV6 = 0x1U;
        CSL_REG32_WR(CSL_CTRL_MMR0_CFG0_BASE + CSL_MAIN_CTRL_MMR_CFG0_LOCK2_KICK0, 0x68EF3490);
        CSL_REG32_WR(CSL_CTRL_MMR0_CFG0_BASE + CSL_MAIN_CTRL_MMR_CFG0_LOCK2_KICK1, 0xD172BC5A);
        CSL_REG32_WR(CSL_CTRL_MMR0_CFG0_BASE + CSL_MAIN_CTRL_MMR_CFG0_ADC0_CLKSEL, CLK_SOURCE_PLL1_HSDIV6);

    This improved the measurement. AIN6 has now no offset error, but AIN7 still measures 6.8mV at 1.8V ref

    Beside this investigation, I found out that we do not configure the PLL1 in the code, but if I read out all registers for the "clock configuration tree tool" the REF_DIV is set to 5 in our device which the tool marks as not correct. Do you know if this could be the default case for a AM2434, in the manual this value is given with 1 as default. Or do you know where this PLL1 will be set up? Could this be done in the sys_firmware part?

    For the Layout, VDDA_ADC0 and ADC0_VREFP are both connected to 1.8V. ADC_VREFN is connected to GND (common GND for all voltages).

    If you provide me an email I may be able to share parts of the schematic as screenshots.

    I will also change the resistor to check the behaviour and tell you the results.

    Regards,
    Robert Czech

  • 0 in reply to Robert Czech
    Prodigy 170 points

    Hello Kallikuppa Sreenivasa,

    if I change the resistor from 820 Ohm to 1k6 Ohm (AIN7 to GND without any signal) the still existing offset of 6.8mV increases from ~6.8mV to ~15.7mV.

    Regards,
    Robert


  • 0 in reply to Robert Czech
    TI__Guru**** 188899 points

    Hello Robert Czech

    Thank you for the inputs.

    Our device expect does not expect offset to differ between channels.

    Is the AN7 close to any other tracks or connectors that makes the channel  susceptible to EOS or any other events.

    I understand you did test on multiple boards.

    Is there a way you could use a new device on one of the boards and test ?

    Regards,

    Sreenivasa

  • 0 in reply to Kallikuppa Sreenivasa
    Prodigy 170 points

    Hello Kallikuppa Sreenivasa,

    we now found the last issue with the AIN7:

    The comment in the adc.h of the SDK 9.1 is misleading and the driver was used wrong:

    /**
 * \brief   This API is used to initialize the ADC module.
 *
 * \param   baseAddr        Base Address of the ADC Registers.
 * \param   errCorrection   Error Correction is enabled if it is TRUE.
 *                          Error Correction is disabled if it is FALSE.
 * \param   errOffset       Write 0 to use internal calibration.
 *                          Write 1 to use EFUSE code.
 * \param   calibration     Writing 0 does not start internal calibration.
 *                          Writing 1 starts internal calibration.
 */
void ADCInit(uint32_t baseAddr,
             uint32_t errCorrection,
             uint32_t errOffset,
             uint32_t calibration);


    So in our code we called this function with:

                uint32_t calibration = 1;
            uint32_t errOffset = 1;
            /* Do the internal calibration */
            ADCInit(adcBaseAdr_, FALSE, errOffset, calibration);


    But if we watch the real implementation of init:
    void ADCInit(uint32_t baseAddr,
             uint32_t errCorrection,
             uint32_t errOffset,
             uint32_t calibration)
{
    uint32_t initMask = 0x0U;

    /* Calculate mask used for ADC init */
    initMask = (calibration << ADC_MISC_AFE_SPARE_INPUT_SHIFT);

    /* ADC Initialization */
    HW_WR_FIELD32(baseAddr + ADC_MISC, ADC_MISC_AFE_SPARE_INPUT, initMask);
}


    There is nothing done with calibration, but the SPARE_INPUT is configured to a value other than 0.

    After setting this value back to 0 with the debugger directly through the register, the offset is gone and all ADC channels are now working without any offset error.

    Beside this, we found out, that the Clock-Tree error message for our PLL1 settings, was configured by the SysFW and was fixed by the new SysFW of SDK 9.2 

    So this issue is now solved for me.

  • 0 in reply to Robert Czech
    TI__Guru**** 188899 points

    Hello Robert Czech

    Good to hear the issue has been resolved and thank you for sharing the resolution, this is appreciated.

    Regards,

    Sreenivasa