AnsweredAssumed Answered

Kinetis kit hardware issues probably resulted from wrong design

Question asked by Bob Fu on Jun 12, 2011
Latest reply on Sep 24, 2011 by Alex Chen

Hi,

 

I just started to use TWRK60N512 and KWIKSTIK-K40 for the past few days, and was frustrated by the hardware issues encountered.

 

1. I wasted a lot time with KwikStik to try to figure out why a simple serial port connected to UART5 testpoints did not work. It turned out that the related testpoints are labeled incorrectly on version 3 of the hardware. Tx is actually connected to the testpoint labeled as CTS (the one close to the PCI edge connector).

 

2.On KwikStik,  3.3V power is way too off: it's 0.5V below specification. The input voltage range of MC34727 is 2.7V to 5.5V, so input voltage of notebook USB port definitely meets the input voltage requirement for it to output 3.3V.  2.8V still works for digital part, but one of main reasons of choosing Kinetis is to use 16-bit ADC, whose precision supposedly should be higher than 10 or 12 bit ADCs in other ARM microcontrollers. After filtering, this voltage is also used as VREFH for ADC. It's 0.5V off on my KwikStik, and who knows how far it's off on another KwikStik.

 

3. On TWRK60N512, I tried to compare ADC result precisions using "3.3V" VREFH and 1.2V internal reference. I used onboard potential meter to provide input voltage below 1.2V. With "3.3V" VREFH, the ADC results are in range of 400 to 1500 ( I think the range is too large for 16-bit ADC). Result of about 500 occurs more often, so it's about 3.3V * 500/65536 = 0.025V. With 1.2V reference, most of the time ADC result is 16120, which translates to 1.2V * 16120/65536 = 0.295V, so there are about 10x difference. May Freescale please investigate what's wrong on TWRK60N512 and possibly also on KwikStik? In case there are doubts about the code I used or developed. The code I used is not mine. The code is described from page 89 to the end of FSL_MQX_3_7_in_CW_10_1.pdf, which comes with MQX installation. ADC results were obtained by reading variable values from debugger, and ADC reference voltage change is done via PE.

 

4. BTW, I also observed a problem with the debugger. After following  page 89 to the end of FSL_MQX_3_7_in_CW_10_1.pdf, we got the following code in main.c:

 

void

AD1_OnMeasurementComplete(LDD_TUserData *UserDataPtr)

{

Error = AD1_GetMeasuredValues(MyADCPtr, (LDD_TData *)&MeasuredValues);

/* Read measured values */

}

 

The problem is that before going inside AD1_GetMeasuredValues, values (addresses) of MyADCPtr and MeasuredValues are different, but the corresponding values after going inside AD1_GetMeasuredValues are the same (as shown in debugger, OS is Windows 7, CW version is 10.1, MQX is 3.7). This gave me hard time to determine what's wrong with the 10x difference mentioned above. BTW, should  (LDD_TData *)MeasuredValues be used instead of  (LDD_TData *)&MeasuredValues?

 

I'd like suggest strongly to add a dedicated 3.x volt reference IC on future versions of Kinetis kits to realize the potential of 16-bit ADC precision, which is one of strong points of Kinetis family. I'm disappointed so far. As for the internal 1.2V reference, when interfacing analog sensors, there are not much sensors that would output signals in range of 0 to 1.2V range, so it's not convenient to use the internal 1.2V reference. Besides it might also has problem as mentioned in the above issue #3.

 

Since I can find these problems with just a few days of usage, it looks like that Freescale also needs to do more testing before releasing the kits.

 

Regards,

bobf

Outcomes