Kinetis kit hardware issues probably resulted from wrong design

[bobf]

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

[ajc2005]

Hi Bob,

I've KwikStik v4 board, and I'm trying to use UART6 through the expansion port A. How do you know it was wired wrong? I don't see it mentioned in the errata. I'm trying to use I2C (not tried out yet) and UART5. Please let me know what gotchas/erratas you know of.

Thanks!

-- Alex

[mjbcswitzerland]

Hi

The Kinetis ADC is a 16 bit wide ADC but will achieve between 13 and 14 bit accuracy according to exact settings (this information was given at a Kinetis seminar by Freescale experts).

This is due to its low power design which allows a very good compromise between speed, power consumption and accuray, it is however not designed to achieve the 16 bit precison that its word length may suggest (emphasis more on low power).

For projects requiring full 16 bit precision its ADC may not be the one to go for - I would check with your FAE to get latest details. Just a warning in case this was not anticipated :smileywink:

Regards

Mark

P.S. I understand that the Tower Kit won EDNs prize for the most innovative product of the year so it can't be that bad. On the other hand, I do wonder whether the judges have ever had to actually work with it....;-). I do wonder how Kinetis developers can work with the 5 UARTs that the Kinetis offers when only one is connected in the kit (for instance).

[bobf]

Hi Mark,

Thanks for sharing the accuracy information regarding ADC in Kinetis. Another ARM chip has 12-bit ADC, but the vendor tells what kind of accuracy can be achieved up front. For Kinetis, we have to test to find out ourselves.

Correct me if I'm wrong here, my understanding is that 13-bit accuracy for 16-bit ADC means that for a stable input, only the last 3-bit of the conversion results would vary from sample to sample, i.e., the maximum conversion result variation range is 8. What I observed is that the accuracy on TWRK60N512 is far lower: more than 100 times lower since the sample variation range is more than 800. Considering time spent and previous hope, I wish it was me who was wrong, and Freescale had tested it before with TWRK60N512 and achieved better accuracy than what I got. I think with mixed signal PCB, there better be speical routing to prevent digital signals from affecting analog signals (or minimize the effect). I'm not sure if this is done for any of Kinetis kits.

Regards,

bobf

[mjbcswitzerland]

Hi Bob

I don't have experience with the ADC myself yet on this board but I would not expect it to be optimal since the board is quite general purpose- therefore I wouldn't expect the maximum resolution to be achieved with it that would be possible by a dedicated layout and careful supply filtering.

The data sheet gives some values which I believe to be around 13,2..13,4 bit accuracy typically, which correlates fairly well with information from Freescale people who had been involved with the ADC development/testing. I would therefore also take these figures as the ones really being achieveable (note that the ADC also can do some averaging so this may be slightly software/configuration dependent - I believe that maximum averaging doesn't automatically result in highest resolution so some experimentation may also be required).

Regards

Mark

[bobf]

Hi Mark,

Even before the kits were ordered, I did not expect to achieve maximum resolution. Just want to point out the problems, and hope the problems can be fixed in future versions of the kits.

Regards,

bobf

[FranknBeans]

Bob,

I was wondering if you ever figured out the problem with the ADC on the tower k60 board. I am having similar troubles and was wondering if there was ever a solution. I tried doing a loop measurement with 10 samples in the loop and was just getting 65535 ten times when using the GetMeasuredValues method. I am using Processor Expert and the potentiometer(R52) and capacitor (C45) provided on the board to read the true sample values. Any help would be appreciated.

[bobf]

No, I did not. I moved on to evaluate/prototype other parts of the project with Kinetis kits. Guess what? My frustration continued. Again, after wasting a lot of time to try to figure out if the problem was in hardware or software, I found out another problem similar to a problem mentioned above: SDA and SCL pad of a I2C port are labelled incorrectly on KwikStik.

Based my experience with these kits and Freescale's errata documents, it seems that among Kinetis kits, quality of KwikStik is the worst. This is understandable in this way: if there are problems with kits designed in house, there are more likly to have more problems with kits developed by 3rd party.

Again, I wish Freescale could fix these problems or improve in the problematic areas mentioned here in future versions of the Kinetis kits. However I don't know if these are also problems in their eyes.

Not sure if you specified reference voltage correctly in Processor Expert. If 1.x V ref was specified, and input was higher than the ref voltage, then you would get 65535 all the time. Please share what you find out.

Good luck!

[FranknBeans]

I have been having troubles with this thing for almost a whole week now and about to give up. No matter what reference voltage I apply I end up getting MeasuredValue to be 65535. I have emailed the "Processor Expert Support and Servicepacks Team" and they have not got back to me about that specific problem yet. The problem I was having before this is that If I set a break point in the example the provide for a "continuous measurement of a selected sample group, with interrupt service," the CancelMeasurements method would not even execute. They solved that issue but it has been 3 days since I have emailed them about this 65535 MeasuredValue problem and no response. Hopefully they are debugging their self and trying to figure this problem out. No matter how I try to get a correct number I get 65535 all the time and its getting very frustrating. Hopefully they will get back to me soon so I can share some good news.

[ProcessorExpert]

Hi,

Please find attached example project that I have created for TWR-K60 board.

This example reads an output from the pin AD1_DN1 (connected to on-board potentiometer) and shows result on console. I have tested it on hardware and haven’t encountered problems.

I recommend to doubleched the wirinig, it might be an issues with connection to CPU input pin.

best regards
Petr Hradsky
Processor Expert Support and Servicepacks Team

[FranknBeans]

I an having a Debug error that I can't figure out for the code attached above. If anyone has had a same issue or could find a solution it would be much appreciated. I will attach my screen shot of my problem. Codewarrior is having troubles debugging any code I make or import. I think this might have to do with a mapping issue but I am not 100% sure on how to solve it. 

Also when i run certain code that I made this error wont affect the code. Sometimes when i do run through some other code I made it will give me a pop up error that has (Can't find a source file at "D:\workspace\ARM_CORTEXM\ARM_CortexM_Component\ewl\EWL_Runtime\Runtime_ARM\Source\abort.c" Locate the file or edit the source lookup path to include its location.) Not sure what the probelm is i think it cant find these files or the workspace they are suppose to be in.

Thank you for your time and please get back to me with any suggestions.

[FranknBeans]

SOLVED THE PROBLEM for both code not working and receiving wrong values . At last I have figured out what was wrong with mine. Apparently one of the default jumper settings on the TWR_SER board needed to be moved for testing the ADC. I fussed around with a couple other boards we had laying around and was receiving the same error and no correct values. Then one of my co-workers received a new board right out of the box. He let me try it out and the code worked right away and got correct values for MeasuredValues. So for the old quick start guide and examples apparently this jumper setting was set incorrectly in host mode and never changed to device mode.

I appreciate all the help you gave us and I can't believe one tiny jumper could cause all of these problems. The jumper that was changed was J16 on the TWR-SER board. It was set on 1-2 being in host mode. For doing the ADC sampling it needed to be set to 3-4 for device mode. I don’t remember reading that anywhere or seeing it anywhere. The default setting has it on 1-2 so it’s a good thing one of the other boards had it changed or I might not have caught this.