VREF_OUT as reference for ADC16 on 32 pin KL17

[nickdolling]

Hi All,

I would like to use the internal 1.2V reference as the refernece for the ADC. Both the datasheet and reference manual suggest this should be possible, however it's not obvious how to configure it.

The only options for reference sources in the ADC config are Vrefh orValth. For Valth it says refer to the chip configuration information (which I assume is the datasheet), but there is nothing there either.

If I select the ALR reference, I get results as though the reference voltage is still 3.3V.

Any sugegstions?

Thanks,

Nick

[Jorge_Gonzalez]

Hello Nick Dolling:

The 1.2V VREF must be enabled from the VREF module with the VREF_SC register. If using KSDK, VREF has its own driver, so you can call VREF_DRV_Init() with the corresponding configuration structure, or use the VREF HAL APIs.

Regards!,
Jorge Gonzalez

[nickdolling]

Hi Jorge_Gonzalez,

Sorry, I'm new here so I'm not sure what the etiquette is, but I'm still waiting for a response to my posts above... not sure if you saw them or get a notification when someone replies to your post.

Thanks,

Nick

[Jorge_Gonzalez]

Hello Nick:

Sorry for the long delay, I had some workload after vacations and I am just catching up.

Let me run some tests with the ADC driver to validate your findings and give you some feedback/responses.

Could you let me know the full part number of your KL17 device?

Regards!

Jorge Gonzalez

[nickdolling]

No problem, it's a KL17Z32VFM4. I can share my initialisation code if it helps.. just give me an email address to send it to rather than posting it here.

Thanks,

Nick

[Jorge_Gonzalez · Accepted solution]

Hello Nick:

I have investigated further on this issue and these are my findings:

1) This is the information in the Reference Manual:

Your device is a 32-pin KL17, so the primary reference option (default reference) is VREF_OUT, while the secondary option (VALT) is VDDA/VSSA. Actually I was wrong that VREF_OUT was the VALT option. Sorry for the confusion.

2) About the KSDK VREF driver, I agree that the TRIM setting is an oversight. I will report this to the developers.

Let me know if you have further doubts.

Best Regards!
Jorge Gonzalez

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

[nickdolling]

Hi Jorge,

Thanks for clearing this up... I had read the section on the ADC numerous times but not picked up the primary/secondary reference subtleties... it would probably help if the Register definition section where REFSEL is described it used the same terminology ie "Primary/Secondary" rather than (or as well as) "Default/Alternate".

Cheers,

Nick

[nickdolling]

BTW - as a side question.. according to the reference manual, the VREF_TRM is loaded with the factory trimmed value out of reset, but using the VREF_DRV_Init() function from the SDK seems to overwrite this... as you can see in my code above, to preserve the factory trimmed value I had to read it first and pass it back in the configuration structure, which didn't seem like something I should have to do..

Is this how it's intended to be used or an oversight in the design of the SDK initialisation for this?

Nick

[JeffLynne]

Nick, I have the same question and it seems no reasonable response is available.

While digging arround VREF with KSDK1.3 and K64F I was surpirsed too that VREF_DRV_Init() calls VREF_HAL_Init() which in turn invokes VREF_BWR_TRM_TRIM(base, 0x00) - setting trim bits to zero.

So, the factory trimmed value had gone to open space.

For me it is a bug in initialization in case user do not want to touch trim values and leave factory defaults. Now user is FORCED to trim by itslef.

[nickdolling]

Hi Jorge,

I am just back from vacation today... thank you for your reply.

I am using the SDk and as far as I can tell I am already doing everything you have suggested.

I configure and enable the VREF using VREF_DRV_Init() with the following configuration :

   vref_user_config_t vrefInit = {

        .chopOscEnable = true,

        .trimValue = VREF_DRV_GetTrimValue(0),

        .regulatorEnable =  true,

        .soccEnable = true ,

        .bufferMode = kVrefModeLowPowerBuffer   };

Then configure the ADC using ADC16_DRV_Init() and the following configuration :

    adc16_converter_config_t adcInit = {

        .lowPowerEnable = true,

        .clkDividerMode = kAdc16ClkDividerOf8,

        .longSampleTimeEnable = true,

        .resolution = kAdc16ResolutionBitOfSingleEndAs10,

        .clkSrc = kAdc16ClkSrcOfAltClk,

        .asyncClkEnable = false,

        .highSpeedEnable = false,

        .longSampleCycleMode = kAdc16LongSampleCycleOf24,

        .hwTriggerEnable = false,

        .refVoltSrc = kAdc16RefVoltSrcOfValt,

        //.refVoltSrc = kAdc16RefVoltSrcOfVref,

        .continuousConvEnable = false,

        .dmaEnable = false  } ;

I measure 1.194V on the 100nF capacitor on PTE30, so it appears the reference is enabled and working.

I measure 0.479V at the ADC channel pin, and with the .refVoltSrc = kAdc16RefVoltSrcOfValt, I get a conversion result of 0x093 (147d), which seems to suggest the reference votlage is 3.3V.

I just noticed however that if I select .refVoltSrc = kAdc16RefVoltSrcOfVref, the conversion result is 0x19E (414d), which looks like the reference is 1.2V nominal.

I have checked the value of the REFSEL bits in ADC0_SC2 and kAdc16RefVoltSrcOfValt sets REFSEL = 1 and kAdc16RefVoltSrcOfVref sets REFSEL = 0, so the SDK is setting the right values however the effect seems the be backwards... REFSEL = 1 appears to select the Vrefh whereas REFSEL = 0 appears to select Valth..

Is it possible that either the documentation of the REFSEL bits (or the silicon implementation, since the way it's documented seems logical) is backwards?

Nick