ADC SyncMode Noise

cancel
Showing results for 
Search instead for 
Did you mean: 

ADC SyncMode Noise

Jump to solution
342 Views
Contributor II

We currently face an issue with the i.MXRT1060 that noise is introduced to our ADC measurements whenever we take two measurements concurrently, but is absent when the Measurements are taken one after another.

This is how we configure the ADC_ETC with a serial measurement:

void ADC_Init(void)
{
    ADC_Configuration();

    adc_etc_config_t adcEtcConfig;
    ADC_ETC_GetDefaultConfig(&adcEtcConfig);
    adcEtcConfig.XBARtriggerMask = 0x1U;
    adcEtcConfig.enableTSCBypass = false;
    ADC_ETC_Init(DEMO_ADC_ETC_BASE, &adcEtcConfig);

    adc_etc_trigger_config_t adcEtcTriggerConfig;
    adcEtcTriggerConfig.enableSyncMode      = false;
    adcEtcTriggerConfig.enableSWTriggerMode = false;
    adcEtcTriggerConfig.sampleIntervalDelay = 0U;
    adcEtcTriggerConfig.initialDelay        = 0U;

    adcEtcTriggerConfig.triggerChainLength  = 1;
    adcEtcTriggerConfig.triggerPriority     = 3U;
    ADC_ETC_SetTriggerConfig(ADC_ETC, 0U, &adcEtcTriggerConfig);

    adc_etc_trigger_chain_config_t adcEtcTriggerChainConfig;
    adcEtcTriggerChainConfig.ADCHCRegisterSelect = 1U << ADC_CHANNEL;
    adcEtcTriggerChainConfig.InterruptEnable = kADC_ETC_InterruptDisable;

    adcEtcTriggerChainConfig.enableB2BMode = true;
    adcEtcTriggerChainConfig.ADCChannelSelect = BOARD_INITPINS_A_CHANNEL;
    ADC_ETC_SetTriggerChainConfig(ADC_ETC, 0U, 0U, &adcEtcTriggerChainConfig);

    adcEtcTriggerChainConfig.enableB2BMode = true;
    adcEtcTriggerChainConfig.ADCChannelSelect = BOARD_INITPINS_B_CHANNEL;
    adcEtcTriggerChainConfig.InterruptEnable = kADC_ETC_Done0InterruptEnable;
    ADC_ETC_SetTriggerChainConfig(ADC_ETC, 0U, 1U, &adcEtcTriggerChainConfig);
}

And the result of the channel A is as following. Sample time is 24kHz and 3000 measurements are taken.

serial.png

If we configure the ADC now in synchronous sampling mode as following:

void ADC_Init(void)
{
    ADC_Configuration();

    adc_etc_config_t adcEtcConfig;
    ADC_ETC_GetDefaultConfig(&adcEtcConfig);
    adcEtcConfig.XBARtriggerMask = 0x1U;   
    adcEtcConfig.enableTSCBypass = false;
    ADC_ETC_Init(ADC_ETC, &adcEtcConfig);

    adc_etc_trigger_config_t adcEtcTriggerConfig;
    adcEtcTriggerConfig.enableSyncMode      = true;
    adcEtcTriggerConfig.enableSWTriggerMode = false;
    adcEtcTriggerConfig.sampleIntervalDelay = 0U;
    adcEtcTriggerConfig.initialDelay        = 0U;

    adcEtcTriggerConfig.triggerChainLength  = 0;
    adcEtcTriggerConfig.triggerPriority     = 3U;
    ADC_ETC_SetTriggerConfig(ADC_ETC, 0U, &adcEtcTriggerConfig);
    ADC_ETC_SetTriggerConfig(ADC_ETC, 4U, &adcEtcTriggerConfig);

    adc_etc_trigger_chain_config_t adcEtcTriggerChainConfig;
    adcEtcTriggerChainConfig.ADCHCRegisterSelect = 1U << ADC_CHANNEL;
    adcEtcTriggerChainConfig.InterruptEnable = kADC_ETC_InterruptDisable;

    adcEtcTriggerChainConfig.enableB2BMode = false;
    adcEtcTriggerChainConfig.ADCChannelSelect = BOARD_INITPINS_A_CHANNEL;
    ADC_ETC_SetTriggerChainConfig(ADC_ETC, 0U, 0U, &adcEtcTriggerChainConfig);

    adcEtcTriggerChainConfig.enableB2BMode = false;
    adcEtcTriggerChainConfig.ADCChannelSelect = BOARD_INITPINS_B_CHANNEL;
    adcEtcTriggerChainConfig.InterruptEnable = kADC_ETC_Done0InterruptEnable;
    ADC_ETC_SetTriggerChainConfig(ADC_ETC, 4U, 0U, &adcEtcTriggerChainConfig);
}

We get very strange results:

synchronous.png

Exactly the same configuration of the ADCs is used in both cases. Noise of about 25bits is introduced and its noteworthy that it is only in positive direction. In both cases we sample VDDA_ADC_3P3/2 at the input, generated directly from VDDA_ADC_3P3 with a voltage divider. VDDA_ADC_3P3 is decoupled with one 220nF and one 1uF capacitor very close the pin. VDDA_ADC_3P3 is shorted with MCU_DCDC_IN as suggested from the reference design. We experience the same issue if we sample GND.

Did anybody experience a similar issue or has an idea where this phenomenon originates from?

Thanks in advance.

Labels (1)
1 Solution
50 Views
Contributor II

We found the problem to be resolved if we use the IPG clock instead of the asynchronous one. More specifically we added these two lines of code:

k_adcConfig.clockSource = kADC_ClockSourceIPG;
k_adcConfig.clockDriver = kADC_ClockDriver4;

This led to the following performance of the ADC on the evaluation board with the supplied sample project

ipg_clock.png

This is the noise we would expect on the MIMXRT1060-EVK with the reference voltage supplied directly from the buck converter. On our custom hardware we achieved the same performance in SyncMode as in serial mode as you can see above in the first picture (+/- 2bits and some outliers). We are still wondering what causes this issue since we have not read about this requirement of not using the asynchronous clock in SyncMode anywhere.

Best,

Alessandro

View solution in original post

0 Kudos
6 Replies
51 Views
Contributor II

We found the problem to be resolved if we use the IPG clock instead of the asynchronous one. More specifically we added these two lines of code:

k_adcConfig.clockSource = kADC_ClockSourceIPG;
k_adcConfig.clockDriver = kADC_ClockDriver4;

This led to the following performance of the ADC on the evaluation board with the supplied sample project

ipg_clock.png

This is the noise we would expect on the MIMXRT1060-EVK with the reference voltage supplied directly from the buck converter. On our custom hardware we achieved the same performance in SyncMode as in serial mode as you can see above in the first picture (+/- 2bits and some outliers). We are still wondering what causes this issue since we have not read about this requirement of not using the asynchronous clock in SyncMode anywhere.

Best,

Alessandro

View solution in original post

0 Kudos
50 Views
Contributor II

Hi

I am working in the team of Alessandro (the original poster).

Here is some more detail.

The problem also goes away if still the asynchronous clock is used, but the bit ADACKEN is set to 0.

We added the following line, then the positive spikes disappeared:

k_adcConfig.enableAsynchronousClockOutput = false;

ADACKEN is 0 after reset, so 0 should be the default value.

But in the adc driver fsl_adc.c, the default for enableAsynchronousClockOutput is set to true. So if you use the driver, this bit is set to 1 by default, and this in turn leads to the problem we experienced.

Is there any explanation, why setting the ADACKEN bit to 1 leads to this effect?

Thanks for investigating,

Daniel

50 Views
NXP TechSupport
NXP TechSupport

Hi all,

Sorry for the later reply.

I got below feedback from i.MXRT product team:

The problem is resulted from the noise cross-talk on the asynchronous clocks' power supply.

Workaround: Using IPG clock; or setting the ADACKEN bit to 1 if IPG clock is not available.

Thanks for the attention.

best regards,

Mike

0 Kudos
50 Views
NXP TechSupport
NXP TechSupport

Hi,

Please check the ADC input pin related PAD Control register [PKE] bit to be 0b0 (disable Pull/Keeper).

 pastedImage_1.png

Thanks for the attention.


Have a great day,
Mike

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

0 Kudos
50 Views
Contributor II

Hi Mike,

Thank you for your answer.

This bit was already set correctly from the PinMux tool. I just verified that this line was present in the pin_mux.c file:

  IOMUXC_SetPinConfig(
      IOMUXC_GPIO_AD_B1_10_GPIO1_IO26,        /* GPIO_AD_B1_10 PAD functional properties : */
      0xB0U);                                 /* Slew Rate Field: Slow Slew Rate
                                                 Drive Strength Field: R0/6
                                                 Speed Field: medium(100MHz)
                                                 Open Drain Enable Field: Open Drain Disabled
                                                 Pull / Keep Enable Field: Pull/Keeper Disabled
                                                 Pull / Keep Select Field: Keeper
                                                 Pull Up / Down Config. Field: 100K Ohm Pull Down
                                                 Hyst. Enable Field: Hysteresis Disabled */

The problem also exists on the MIMXRT1060-EVK evaluation board. I attached a small sample program based on the "adc_etc_hardware_trigger_conv" example from the SDK. In the attached program PIN J23-1 is sampled which should be connected to half the reference voltage (with a simple voltage divider) that we get from J24-7 and J24-8. We write the ADC Values to the array "adc_values" which we extract through the memory browser after a few seconds after starting the program (we simply halt the program with a breakpoint). The adc_values can then be viewed with the file byteplotter.py which is present in the attached folder as well.

On the evaluation board we then get this result:

eval_board.png

Again we see a significant noise in positive direction (and some kind of capping in negative direction?).

I hope its clear how to run the sample program. Otherwise do not hesitate to ask.

Best,

Alessandro

0 Kudos
50 Views
NXP TechSupport
NXP TechSupport

Hi Alessandro,

Thanks for the detailed info.

I need to check with i.MXRT product team about how to improve the ADC performance in sync. mode.

I will update when there with any feedback.

Thanks for the patience.

best regards,

Mike

0 Kudos