Has anyone see occasional corrupted (all 1s) KL03 ADC values?

[rickstuart]

We have similar code (admittedly not exactly the same code) which runs on the KL03 and the KL17.  All ADC conversions appear to work on the KL17.  However, on the KL03 we occasionally see 0x0fff read (about 10% to 20% of the time).

We can work around this problem on the KL03 after considerable efforts are made to avoid taking an ADC conversion during the execution of code driven by PORTB interrupts.  No such efforts have been necessary when similar code is run on the KL17.

The code driven by the PORTB interrupt also uses the KL03 TIMER1 interrupt and also adjusts the processors speed in order to conserve power.

We have burned though many ideas of why this happens.  One of the few options left it so accuse the KL03 design of hardware defects.  But before doing that, I thought I would solicit any additional ideas from this community of users.

-thanks

[rickstuart]

Problem solved?

Let me explain:

1. First this problem did not exist on the KL17.

2. This problem only existed on the KL03.

What's the difference?  The KL03 we are using is a QFN 24pin processor.  Less than 32 pins.  In such a configuration the external voltage reference pins are gone.  Missing.  If we read the KL03 specifications regarding the REFSEL bits in register ADCx_SC2 we read "00 Default voltage reference pin pair, that is, external pins VREFH and VREFL"  ...which, as stated, do not exist on the 24 pin KL03 QFN package.  So so we think!  The only alternative (because all other combinations of 2 bits are marked as "Reserved") is: "01 Alternate reference pair, that is, VALTH and VALTL . This pair may be additional external pins or
internal sources depending on the MCU configuration. See the chip configuration information for
details specific to this MCU" ...so we pick it - as (as stated above) the pin pair are missing on the KL03 QFN 32 pin package.

Boy-o-boy were we wrong ... or so we are thinking now!

What REFSEL = 01 is selecting....

Section 28.1.2 says: "Pin PTB2 can be configured to VREF_OUT, which needs to connect a capacitor to
ground when 1.2 V VREF is enabled."  This is pin 14 on a KL03 24pin QFN package. 

Section 28.1.3 says: "VREF_OUT - connected as the VALT reference option."

So...  If setting REFSEL to 01 connects to VALTH and VALTL. And if we assume VALTH is VALT.  And we assume VREF_OUT is connected to VALT.  And we assume this is pin 14 on the KL03 24pin QFN package.  And if we were using pin 14 as an input from external logic....

...when the external logic drove pin 14 high to 3.3 the ADC would appear to work.  But if the external logic drove pin 14 low the ADC would report the highest value possible.

But that's a lot of assumptions.  So here's the question to NXP, are the assumptions correct?  Did we really program the KL03 ADC to use pin 14?

Further, here's the second question, given there are only 2 alternatives.  What are we actually referencing the KL03 QFN 24pin processor's ADC when we set REFSEL to 00?

-thanks

[Robin_Shen · Accepted solution]

Hi rick,

Sorry for the late reply!

According to the description "28.1.3 ADC Reference Options" of KL03P24M48SF0RM.

• VDD/VSS - connected as the primary reference option
• VREF_OUT - connected as the VALT reference option

If setting REFSEL to 00, VDD/VSS connected as the primary reference option.

If setting REFSEL to 01 connects to VALTH and VALTL, VREF_OUT is connected to VALTH. 

VREF_OUT is 1.2v internally-generated voltage reference output. You can't drove VREF_OUT(pin 14) high to 3.3v. So if the ADC input voltage higher than VREF_OUT(1.2v), you will get 0x0fff.

For more detail about the VREF_OUT, you can read "3.6.3 Voltage reference electrical specifications" of KL03P24M48SF0 and "Chapter 30 Voltage Reference (VREF)" of KL03P24M48SF0RM.

Best Regards,

Robin

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

[egoodii]

28.7.1.2 has this to say:

In some packages, the external or alternate pairs are connected in the package to VDDA and VSSA, respectively. One of these  positive references may be shared on the same pin as VDDA on some devices. One of these ground references may be shared on the same pin as VSSA on some devices.

This is common across (formerly Freescale) processors --- pin-constrained packages will directly tie VrefH to VddA, and VrefL to VssA.  So we can assume that in this package '00' will select VddA/VssA as the reference voltage.

[rickstuart]

I can't post the code.  What I may do, time permitting and if by then we have not solved the problem, is post an example of code that exhibits the same problem.

The part is a KL03T5V.  This information (KL03 chip markings) is not in the NXP KL03 specification.  They (NXP) know about that omission now.  We have more than a half dozen boards built up with this part and all that I've tested have this problem.

Briefly, what we do when the ADC works is to wake up using the low power timer and take ADC samples (using TIMER0, TIMER0-THRESHOLD-CROSSING-TO-TOGGLE-A-PIN & TIMER0-OVERFLOW-TO-TRIGGER-THE-ADC) while running the processor at 48MHz.  What we do when the ADC occasionally fails is to wake up using pin activity on PORTB, use TIMER1 and momentarily change the processor to run at a slower rate to conserve power.  If we change things around such that we never wake up using PORTB, we do not expect to see any ADC failures.  When the ADC fails, the value 0x0fff is read from the ADC register.  We are asking the ADC hardware to average 4 samples for us.

-thanks

[Robin_Shen]

Hi Rick,

Would you please attached your project here? It will be useful to the problem solution.

What's the part number of your KL03? "P03T5V" means PKL03Z32VFK4.

If you have test ADC example in the Kinetis SDK v2?

Best Regards,

Robin