topic Re: Help Me Understand KL27 ADC Continuous Conversion in Kinetis Software Development Kit

Help Me Understand KL27 ADC Continuous Conversion

bhenning — Thu, 27 Aug 2020 18:09:56 GMT

Hi,

I think I am failing to understand some key aspect of "continuous conversion" on the KL27 ADC0 peripheral. Having it set to enabled results in the R register saturating (0x0FFF in 12-bit mode) and staying there. Here's some background:

Dev Kit: FRDM-KL27Z

MCUXpresso 11.2

FRDM-KL27Z SDK 2.8.0

What I want is for the ADC to be constantly running in the background, doing conversions, and triggering user code via its COCO interrupt. My hope is that this produces a reasonably-consistent sampling rate of an external signal.

If continuous conversion is NOT enabled, I get exactly one interrupt, after the ADC is initially configured. If continuous conversion IS enabled, I get ongoing interrupts, which makes sense.

However, when continuous conversion IS enabled, the result register ADC0->R[0] saturates to 0x0FFF and stays there. I can replicate this with the SDK adc16_interrupt example, by changing nothing except setting the continuousConversions field in the configuration struct to true:

// This gives reasonable conversion results:
 adc16ConfigStruct.enableContinuousConversion = false;
// This causes the R register to saturate, giving constant 0x0FFF:
// adc16ConfigStruct.enableContinuousConversion = true;

I know the problem is with my understanding of "continuous conversion mode" so I really hope someone will have the time to help me understand it. Why does the result register saturate? What do I need to do in the code, or in the configuration, to get valid results using continuous conversion mode?

Thanks very much.

Re: Help Me Understand KL27 ADC Continuous Conversion

kerryzhou — Tue, 01 Sep 2020 06:57:57 GMT

Hi bhenning,

From the KL27 reference manual, we can get some ADC continuous conversions:

If continuous conversions are enabled, a new conversion is automatically initiated after
the completion of the current conversion. In software triggered operation, that is, when
SC2[ADTRG] = 0, continuous conversions begin after SC1A is written and continue
until aborted. In hardware triggered operation, that is, when SC2[ADTRG] = 1 and one
ADHWTSn event has occurred, continuous conversions begin after a hardware trigger
event and continue until aborted.
If hardware averaging is enabled, a new conversion is automatically initiated after the
completion of the current conversion until the correct number of conversions are
completed. In software triggered operation, conversions begin after SC1A is written. In
hardware triggered operation, conversions begin after a hardware trigger. If continuous
conversions are also enabled, a new set of conversions to be averaged are initiated
following the last of the selected number of conversions.

So, if you enable the continuous converstion, if you also enable the ADC converstion complete interrupt ADCx_SC1n[AIEN]=1, then after you start the converstion, the interrupt will be entered continuously, and you can read the ADC data in the interrupt.

I suggest you check the register, debug it, when you enable the continuous, do you check the ADCx_SC2[ADCO] , whether it is set or not? Please debug it on your side.

Best Regards,

Kerry

-------------------------------------------------------------------------------
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.
-----------------------------------------------------------------------------

Re: Help Me Understand KL27 ADC Continuous Conversion

bhenning — Tue, 01 Sep 2020 14:45:54 GMT

Hello Kerry,

There is no ADCO field in ADCx_SC2. Perhaps you meant to refer to ADCx_SC3? Yes, the ADCO bit is set in this register.

My interrupt checks ADCx_SC1 and only reads R if COCO was set. R always gives 0x0FFF regardless of the actual input voltage.

I also tried using 16-bit SE mode, and that had exactly the same behavior: R always reads as 0xFFFF.

Here is my actual interrupt code:

void ADC_Handler( void ) { uint32_t sc1 = ADC0->SC1[0]; uint32_t sc2 = ADC0->SC2; uint32_t sc3 = ADC0->SC3; if(sc1 & ADC_SC1_COCO_MASK) { uint16_t v = ADC0->R[0]; // ... do something with the value [redacted] ... } }

When I set a breakpoint beyond the line that reads from ADC0->R[0], I can inspect the values. Here is a set of values observed in the debugger:

SC1	0b1100 0000	COCO, AIEN are set
SC2	0b1000 0000 (sometimes 0b0000 0000)	ADACT set (sometimes not)
SC3	0b0000 1100	ADCO, AVGE are set
R	0b0000 1111 1111 1111 (0x0FFF)

These results are consistent with every pass through the interrupt handler.

According to the reference manual, regarding hardware averaging:

[...] after the selected number of conversions are completed, the average conversion result is transferred into the data result registers, Rn, and SC1n[COCO] is set.

and

If hardware averaging is enabled, the respective SC1n[COCO] sets only if the last of the selected number of conversions is completed.

This suggests to me that if COCO is set, the R value should be valid. Why is it always reading 0x0FFF?

Re: Help Me Understand KL27 ADC Continuous Conversion

bhenning — Tue, 01 Sep 2020 14:55:11 GMT

Please be sure to read my previous comments. Apparently I ran out of time to edit the post to add this:

SC3[CALF] is also set (an error in my message above). The reference manual indicates that "[t]he calibration sequence will fail if SC2[ADTRG] = 1, any ADC register is written, or any stop mode is entered before the calibration sequence completes" but none of these causes are occurring; SC2[ADTRG] = 0, no ADC register is written during calibration, and no stop mode is entered during calibration. So now there is a new question: Why is CALF being set?

Re: Help Me Understand KL27 ADC Continuous Conversion

kerryzhou — Wed, 02 Sep 2020 07:35:39 GMT

Hi bhenning,

Thanks for your updated information, I also meet the issues when in the ContinuousConversion mode.

I find if I connect to 0V, it can give out the result related 0V, but when the ADC pin input voltage is upto 0.2V, the output value will be 4037.

So, Still need more time to check the software trigger continuous mode internally, really have the issues when I test the FRDM-KL27 with SDK ADC project, but when I disable the continuous conversion mode, just use one trigger mode, it works OK.

Could you please also help to test the continuous_dma project on your side:

SDK_2.8.0_FRDM-KL27Z\boards\frdmkl27z\driver_examples\adc16\continuous_dma

When you give about 1V voltage, what's the result you will get? I find this project test result also have issues on my side. please help to check it, whether you also get the issue result.

If yes, I will report this issue internally.

Waiting for your updated information.

Best Regards,

Kerry

Re: Help Me Understand KL27 ADC Continuous Conversion

bhenning — Wed, 02 Sep 2020 14:29:47 GMT

Hello Kerry,

That makes sense. The project on which I am working has external buffer circuitry that scales an external input into acceptable range for the ADC, and that buffer's output is always above 0 V. So it will take me a little extra time to set up to test this scenario. I will report my findings as soon as I have tested.

Thanks.

Re: Help Me Understand KL27 ADC Continuous Conversion

bhenning — Wed, 02 Sep 2020 17:09:13 GMT

I have hooked up a voltage source directly to the ADC input pins as configured by the continuous_dma example (J4 pin 2) and tested over the range of 0V - 1 V. My observations:

Response is extremely nonlinear over the range of ADC values (0 - 0xFFFF) and most codes are missing
Response shows significant hysteresis at low end of input range
ADC output jumps in large values, skipping over many codes
ADC output sticks around 25% (consistent output of 16132) with an input 40 mV - 80 mV
Output jumps to 31745 and sticks there over the range 90 mV - 200 mV
Output jumps to 47877 at 300 mV
At 400 mV, the output hovers around 55746 - 55936 with noticeable missing codes
At 500 mV, the output code saturates (65535) and does not change over the rest of the input range up to 1.0 V

Thanks.

Re: Help Me Understand KL27 ADC Continuous Conversion

kerryzhou — Fri, 04 Sep 2020 03:05:54 GMT

Hi bhenning

Thanks so much for your updated information and the detail test result.

This issue is really a little strange, I will report and talk to our internal side about the ADC continuous issues.

If I get any updated information, I will let you know ASAP.

In the meanwhile, you can use the onetime trigger to realize the ADC conversion at first.

Thanks a lot for your understanding.

Wish it helps you!

If you still have questions about it, please kindly let me know!

Best Regards,

Kerry

-------------------------------------------------------------------------------

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.

-----------------------------------------------------------------------------

Re: Help Me Understand KL27 ADC Continuous Conversion

kerryzhou — Mon, 07 Sep 2020 09:11:54 GMT

Hi Kerry,

So sorry for my later reply.

I find it is my mistake, I ignore the hardware, the FRDM-KL27 VFEFH is not connected to 3.3V in default.

R17 is not connected, after I connect the VREFH, it works OK now.

Still take SDK_2.8.0_FRDM-KL27Z\boards\frdmkl27z\driver_examples\adc16\interrupt

as an example,

config->enableContinuousConversion = true;//false;

/* * Copyright (c) 2013 - 2015, Freescale Semiconductor, Inc. * Copyright 2016-2018 NXP * All rights reserved. * * SPDX-License-Identifier: BSD-3-Clause */ #include "fsl_debug_console.h" #include "board.h" #include "fsl_adc16.h" #include "pin_mux.h" #include "clock_config.h" /******************************************************************************* * Definitions ******************************************************************************/ #define DEMO_ADC16_BASE ADC0 #define DEMO_ADC16_CHANNEL_GROUP 0U #define DEMO_ADC16_USER_CHANNEL 1U /* PTE16, A0-ADC0_SE1, J4-2 on FRDM-KL27Z. */ #define DEMO_ADC16_IRQn ADC0_IRQn #define DEMO_ADC16_IRQ_HANDLER_FUNC ADC0_IRQHandler /******************************************************************************* * Prototypes ******************************************************************************/ /******************************************************************************* * Variables ******************************************************************************/ volatile bool g_Adc16ConversionDoneFlag = false; volatile uint32_t g_Adc16ConversionValue; volatile uint32_t g_Adc16InterruptCounter; const uint32_t g_Adc16_12bitFullRange = 4096U; /******************************************************************************* * Code ******************************************************************************/ void DEMO_ADC16_IRQ_HANDLER_FUNC(void) { g_Adc16ConversionDoneFlag = true; /* Read conversion result to clear the conversion completed flag. */ // if(!(ADC0->CFG2 & ADC_SC2_ADACT_MASK)) if (( (ADC0->SC1[0]) & ADC_SC1_COCO_MASK ) == ADC_SC1_COCO_MASK) { g_Adc16ConversionValue = ADC16_GetChannelConversionValue(DEMO_ADC16_BASE, DEMO_ADC16_CHANNEL_GROUP); g_Adc16InterruptCounter++; PRINTF("ADC Value: %d\r\n", g_Adc16ConversionValue); } SDK_ISR_EXIT_BARRIER; } /*! * @brief Main function */ int main(void) { adc16_config_t adc16ConfigStruct; adc16_channel_config_t adc16ChannelConfigStruct; BOARD_InitPins(); BOARD_BootClockRUN(); BOARD_InitDebugConsole(); EnableIRQ(DEMO_ADC16_IRQn); PRINTF("\r\nADC16 interrupt Example.\r\n"); /* * adc16ConfigStruct.referenceVoltageSource = kADC16_ReferenceVoltageSourceVref; * adc16ConfigStruct.clockSource = kADC16_ClockSourceAsynchronousClock; * adc16ConfigStruct.enableAsynchronousClock = true; * adc16ConfigStruct.clockDivider = kADC16_ClockDivider8; * adc16ConfigStruct.resolution = kADC16_ResolutionSE12Bit; * adc16ConfigStruct.longSampleMode = kADC16_LongSampleDisabled; * adc16ConfigStruct.enableHighSpeed = false; * adc16ConfigStruct.enableLowPower = false; * adc16ConfigStruct.enableContinuousConversion = false; */ ADC16_GetDefaultConfig(&adc16ConfigStruct); #ifdef BOARD_ADC_USE_ALT_VREF adc16ConfigStruct.referenceVoltageSource = kADC16_ReferenceVoltageSourceValt; #endif ADC16_Init(DEMO_ADC16_BASE, &adc16ConfigStruct); ADC16_EnableHardwareTrigger(DEMO_ADC16_BASE, false); /* Make sure the software trigger is used. */ #if defined(FSL_FEATURE_ADC16_HAS_CALIBRATION) && FSL_FEATURE_ADC16_HAS_CALIBRATION if (kStatus_Success == ADC16_DoAutoCalibration(DEMO_ADC16_BASE)) { PRINTF("ADC16_DoAutoCalibration() Done.\r\n"); } else { PRINTF("ADC16_DoAutoCalibration() Failed.\r\n"); } #endif /* FSL_FEATURE_ADC16_HAS_CALIBRATION */ PRINTF("ADC Full Range: %d\r\n", g_Adc16_12bitFullRange); PRINTF("Press any key to get user channel's ADC value ...\r\n"); adc16ChannelConfigStruct.channelNumber = DEMO_ADC16_USER_CHANNEL; adc16ChannelConfigStruct.enableInterruptOnConversionCompleted = true; /* Enable the interrupt. */ #if defined(FSL_FEATURE_ADC16_HAS_DIFF_MODE) && FSL_FEATURE_ADC16_HAS_DIFF_MODE adc16ChannelConfigStruct.enableDifferentialConversion = false; #endif /* FSL_FEATURE_ADC16_HAS_DIFF_MODE */ g_Adc16InterruptCounter = 0U; ADC16_SetChannelConfig(DEMO_ADC16_BASE, DEMO_ADC16_CHANNEL_GROUP, &adc16ChannelConfigStruct); while (1) { GETCHAR(); g_Adc16ConversionDoneFlag = false; /* When in software trigger mode, each conversion would be launched once calling the "ADC16_ChannelConfigure()" function, which works like writing a conversion command and executing it. For another channel's conversion, just to change the "channelNumber" field in channel configuration structure, and call the function "ADC16_ChannelConfigure()"" again. Also, the "enableInterruptOnConversionCompleted" inside the channel configuration structure is a parameter for the conversion command. It takes affect just for the current conversion. If the interrupt is still required for the following conversion, it is necessary to assert the "enableInterruptOnConversionCompleted" every time for each command. */ /* ADC16_SetChannelConfig(DEMO_ADC16_BASE, DEMO_ADC16_CHANNEL_GROUP, &adc16ChannelConfigStruct); while (!g_Adc16ConversionDoneFlag) { } */ // PRINTF("ADC Value: %d\r\n", g_Adc16ConversionValue); // PRINTF("ADC Interrupt Count: %d\r\n", g_Adc16InterruptCounter); } }

When I change the voltage, the conversion result is changed, it is correct, the same one time trigger.

So, do you check your hardware, do you add the VREFH?

SDK_2.8.0_FRDM-KL27Z\boards\frdmkl27z\driver_examples\adc16\continuous_dma

is also correct, this is the test result:

ADC value: 0
ADC value: 0
ADC value: 0
ADC value: 406
ADC value: 409
ADC value: 407
ADC value: 3706
ADC value: 3718
ADC value: 3725
ADC value: 5271
ADC value: 5274
ADC value: 5275
ADC value: 7059
ADC value: 7047
ADC value: 7059
ADC value: 9142
ADC value: 9149
ADC value: 9164
ADC value: 11465
ADC value: 11477
ADC value: 11410
ADC value: 13772
ADC value: 13753
ADC value: 13775
ADC value: 16960
ADC value: 17001
ADC value: 17003
ADC value: 20073
ADC value: 20074
ADC value: 20070
ADC value: 23399
ADC value: 23403
ADC value: 23406
ADC value: 26512
ADC value: 26497
ADC value: 26508
ADC value: 30065
ADC value: 30079
ADC value: 30088
ADC value: 32341
ADC value: 32368
ADC value: 32358
ADC value: 35233
ADC value: 35245
ADC value: 35284
ADC value: 38089
ADC value: 38134
ADC value: 38123
ADC value: 42358
ADC value: 42354
ADC value: 42360
ADC value: 47254
ADC value: 47315
ADC value: 47326
ADC value: 50636
ADC value: 50639
ADC value: 50618
ADC value: 53282
ADC value: 53296
ADC value: 53290
ADC value: 57946
ADC value: 57970
ADC value: 57941
ADC value: 64402
ADC value: 64390
ADC value: 64400
ADC value: 64405
ADC value: 64402
ADC value: 64399

Wish it helps you!

If you still have questions about it, please kindly let me know!

Best Regards,

Kerry

-------------------------------------------------------------------------------

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.

-----------------------------------------------------------------------------

Re: Help Me Understand KL27 ADC Continuous Conversion

bhenning — Mon, 14 Sep 2020 14:11:14 GMT

Hello Kerry,

Thanks for all of this information. Clearly we both missed this key detail about VREFH. I was on vacation all last week, but should be able to verify this today. I will return with an update as soon as I have one.

Cheers!

Re: Help Me Understand KL27 ADC Continuous Conversion

kerryzhou — Tue, 15 Sep 2020 02:58:10 GMT

Hi bhenning

You are welcome!

After you test it, please also tell me your test result.

If you still have issues, you also can use the NXP official board and test it like me, the issue should be solved.

Wish it helps you!

If you still have questions about it, please kindly let me know!

Best Regards,

Kerry

-------------------------------------------------------------------------------

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.

-----------------------------------------------------------------------------

Re: Help Me Understand KL27 ADC Continuous Conversion

bhenning — Tue, 15 Sep 2020 13:46:53 GMT

Hello Kerry,

Our current prototype is a carrier that the FRDM-KL27Z plugs into, an easy intermediate step before we design the final product.

If I bridge the R17 footprint with solder (I don't have 0-ohm resistors handy...), then the problem does indeed go away. I've marked your reply that contains that information about R17 as the accepted solution.

Thank you!