K10 Microcontroller XTAL32 and EXTAL32

[haojianxu]

I am a new user of Kinetis micro controller. I am planning to use the process on motion controller application. After quickly go through the datasheet, I am not get a clear picture about XTAL32 and EXTAL32 pins.

1. Do I need hook a 32KHz oscillator at EXTAL32 pin? I assumed the microcontroller has its own internal clock.

2. What kind of applications need there 2 pins? Can I left them floating if I don't need them?

Thanks,

HJ

[Stano]

Hello HJ,

there are two pairs of the EXTAL/XTAL pins. The first pair EXTAL0/XTAL0 belongs to oscillator module when the external crystal is used. The EXTAL0 pin can also serve as input for the external clock source (external oscillator), or can be used as GPIO or other functionality pin. The XTAL0 is the oscillator output pin, when the external crystal is used. It can be used also as the GPIO or other functionality pin.

The second pair EXTAL23/XTAL32 belongs to internal RTC (real time clock) oscillator and has to be used with the external 32,768kHz crystal. These two pins have no other functionality. If you don't want to use RTC module and not use the external clock crystal, connect the EXTAL32 pin to ground. The XTAL32 pin left open - not used. The detail description you can find in the K10...RM - reference manual on NXP web.

Best Regards,

Stano.

[haojianxu]

Hi Stano,

Thanks for clarification. I think I don't need EXTAL32 in motion control application.

Can you give me some examples where RTC clock is necessary ? I don't want miss anything in the hardware design.

Haojian

[Stano]

Hi HJ,

the RTC - Real time Clock feature is needed in all application, where you can use such "time stamp" when such event has to be done or has be recorded. I suggest you to integrate the small RTC 32,768kHz crystal on your hardware board - it is only one component which can be used or not in final application. The RTC modul has separated power supply VBAT, it can run even if the rest of chip is in power down mode and this RTC oscillator can provide the reference clock source for the main clock oscillator of the MCU in run mode.

So my suggestion - implement the external crystal connected to the EXTAL32/XTAL32 pins.

Best Regards,

Stano.

[haojianxu]

Hi Stano,

I take your suggestion. I am using K10 to interface with a quadrature encoder signal A/B/index. I can find FTM1_QD_PHA, and FTM1_QD_PHB as endoder A/B inputs. I am not figuring out which pin I can use to capture encoder index?

Please advice.

Thanks,

HJ

[Stano]

Hi HJ,

as you know from reference manual, the phase A and B of the quadrature encoder are connected to the FTM1_QD_PHA, and FTM1_QD_PHB inputs. Then the FTM module can provide information about real position (angle) of the encoder wheel. The index output of the encoder serves as the supplementary output which can be used for the actual position correction for each turn of the encoder. In case of such reason (mechanical noise of the sensed wheel) the output value of the quad decoder could contain such small inaccuracy (one or several impulses), the index signal provides accurate information about the basic wheel position. So this signal has to be sensed e.g. as interrupt on GPIO pin and then check the quad decoder value, if it provides accurate value which equals to basic wheel position. If not the value has to be corrected (e.g. reset to zero).

The FTM counter is 16-bit only, it has to be checked the timer overflow event to catch the information and add it to final position result.

I hope it can help you, but you are welcome if you need such help.

Best Regards,

Stano.

[egoodii]

It doesn't HAVE to be the indirect GPIO-interrupt process -- the 'odd path' thru the analog comparator supplies perfectly accurate edge-count-capture-points 'out beyond 1M steps per second' (as long as the particular chip-in-use HAS such a path-to-capture-register available).  It does, however, NOT exactly capture the 'direction' information at the time -- for that we DO have to rely on 'pretty darn quick' manual-read of the 'current direction' flag.

But yes, counting beyond 16 bits is 'much less than perfect'.  You will have to nab the 'overflow interrupts' and keep your own counter-extension, and 'fret' over 'high speed bounce' right at the overflow point and the real potential to miss one or more over/under-flow events.

[haojianxu]

Hi Earl and Stano,

Thanks for both you for the help. Based on your info, it looks like K10 does not have designed-in encoder index capture unit.

1. My initial thought to use GPIO interrupt if there is no dedicated capture unit.

2. Earl, I assumed you hooked index input to CMPx_INx pin for capture. Right? If it works, it is great.

3. Is it possible to use FTM0_CHx pin to generate index capture ?

Thanks,

HJ

[egoodii]

Unfortunately, no you cannot use the 'regular' FTMx_CHy pins for index -- the FTM blocks that HAVE the quadrature-decode-mode only HAVE two direct timer-input-pins, and those must be your PHA/B inputs.

I haven't seen here where you give an exact K10 part #, so I can't verify these options, but K10P144M120SF3RM.pdf has this to say:

3.8.2.7 Input capture options for FTM module instances

The following channel 0 input capture source options are selected via SIM_SOPT4. The

external pin option is selected by default.

• FTM1 channel 0 input capture = FTM1_CH0 pin or CMP0 output or CMP1 output

• FTM2 channel 0 input capture = FTM2_CH0 pin or CMP0 output or CMP1 output

as set in SIM_SOPT4 18/19 and 20/21.  Just use a 'nice' center-trip-voltage for the comparison-voltage (internally set) to give you a nominal 'digital input'-like function.  And that comparator-output will then be the 'channel 0 input' for the 'channel 0' logic of the associated FTM (figure 40-1, same pdf), and in which you can set the edge to capture, OR enable the 'dual edge mode' using both channels 0 and 1, so you have the count at both edges in C0V and C1V -- and from THAT and the 'direction' you pick up on an interrupt to read said channel(s) you can decide which edge you will 'pick' (assuming your index-width might span more than one PHA/B edge).

And yes, this all works VERY well.  My interface is to a large linear-encoder, capable of >25Medges/sec, and I find this index gets me the EXACT count out 'past 1M/sec'--far faster than where one usually is 'looking' for said index-alignment signals.  I expect this 'indirect path thru a comparator' incurs a delay on the order of 100ns, so somewhere around 10Medges/s we would get 'behind' an edge.

Unfortunately, said encoder also spans 1M counts, so extending the limited 16bit count is irritating.

[Stano]

Hi Earl,

you are right, it doesn't have to be the indirect GPIO sensing. The K10 MCU has implemented special quad decoder module inside FTM, which process whole decode task. If I understand well, HJ was asking how to use the "index" signal from quad encoder. Let wait for HJ answer.

Best Regards,

Stano.

[egoodii]

I am not 'highly familiar' with your particular family member, but you can check my post  onQEI inputs, and index capture where on my version I hook index thru a comparator (in high speed mode!) I can select as an 'input capture' source, and thru one or two capture registers you can get hardware to grab the count at either or both index edges as they go by, and interrupt thereon.  I have found this to be very effective, if a little obtuse.