Running the K64 from its RTC oscillator - does it work?

[mjbcswitzerland]

Hi All

I have been testing various clocking configurations and wanted to try using the 32.768kHz RTC oscillator as external input to the FLL and generate a 95.97MHz core clock.

In fact it looked quite simple to do but I didn't manage it because as soon as the FLL input was switched from the internal IRC to external clock the initialisation would hang waiting for the FLL input to be selected. Before selecting the input I have ensured that the RTC oscillator is running and set the external oscillator for it (MSG_C7 = 1) and FRDIV is 0 (/1) so that the FLL input is at the correct speed.
IREFS can be cleared in MSG_C1 but the status register still shows that the 32kHz IRC is being used.

Here is also the MCG diagram that I use to which I have added register controls so that it is easier to understand and check (showing the path that I would like to switch through)

Note: When testing the IRC48MCLK path I originally had a similar issue in that I was switching the MCGOUTCLK to it but the status register was showing that it was not being used. Only when I remembered that the IRC48M has to be enabled in the USB module first did the status register display that it had indeed been correctly set and so I am suspectig that the signal is not actually at the input (and the switch is not actually switching and the IRC is still being used). But I couldn't see what was missing and no amount of trying resulted in any success.

It was one of those rare instances that I decided to see how PE does it right since it obviously had me beat.

So I set up PE to do the same:

And I stepped though the code to get a lesson in how thing should be done....

And what hapens... it gets stuck as well as soon as it tries to switch the FLL input to the external RTC clock source

	while((MCG_S & MCG_S_IREFST_MASK) != 0x00U) { /* Check that the source of the FLL reference clock is the external reference clock. */
	}

It spins here forever...

So now I am wondering:

- does my chip have a broken track between the RTC input and the FLL input switch?
- Should the PE code work or has it never been tested?
- Is it actually possible to connect the RTC clock to the FLL input?

Anyone done it successfully??

Regards

Mark

[neilporven]

I am using a K64 processor on a custom board and KDS 3.0.0

It seems everyone is having problems with this RTC stuff (including myself)....:smileycry:

I have a 32.786kHz crystal on EXTAL32 and XTAL32 and I want to set it up on PE(Processor Expert).  Unfortunately, PE has so many tabs (Clock sources, clock source setting, clock configurations, clock this .....clock that....... I am not sure which tab to select?

Above, I selected the one with the arrow! 

I have the following questions:

1.  Can someone tell me if I am using the right tab?

2.   If I am using the wrong tab, can someone direct me to the right one? Plus should I go to any other tab and check something or un-check something?

3.   I am concern with the statement above, " If the VBAT of the K64 is not connected the RTC will also not work and any attempt to access it will result in a hard-fault. This was also found in a product development that I was involved with so it is a "general" requirement."  Is this true?

4.  What document/errata does it state that if VBAT is not connected, then the RTC will not work?

I might have more questions....

Thank you.

[mjbcswitzerland]

Hello Neil

I used the same TAB as you to check out what PE did - In one case it worked and in another it didn't. It generates a lot of code, of which just a couple of lines are relevant for this case (and I expect that it wil be quite PE version dependent so you may get different behavior if using a different versions). It is best to start with a deleted Flash and make sure that the RTC has been powered down since the code may not be able to handle the case where the RTC was already running, in case it is being initialised by code in Flash before loading the new code.

Simply writing the handful of lines of code (as above) is as easy and is then reliable (and commented so that it is understandable what it is doing).

I don't think that the fact that the RTC needs a voltage for its registers to be accessed is an errate, but a 'normal' fact since the RTC is powered by this input and nothing else. The effect is easy to test by adding and removing the VBAT power supply but it may not be made that clear in the documentation that one must avoid trying to access it if the supply is missing since it 'does' indeed result in a hard fault.

Regards

Mark

Kinetis: µTasker Kinetis support

K64: µTasker Kinetis FRDM-K64F support  / µTasker Kinetis TWR-K64F120M support

For the complete "out-of-the-box" Kinetis experience and faster time to market

[priyankb]

Hi Mark,

You said "The effect is easy to test by adding and removing the VBAT power supply but it may not be made that clear in the documentation that one must avoid trying to access it if the supply is missing since it 'does' indeed result in a hard fault.".

Now is there any way to check whether adequate voltage is available through VBAT pin or battery is connected to VBAT at all so as to avoid hard fault reading RTC registers?

I know one could be by using ADC.

Thank you.

[mjbcswitzerland]

Hi Priyank

Generally one would power VBAT from both a battery AND the normal power supply (that powers the chip) via diodes and so it would not be possible for a hard fault to occur when the chip is running. However, if the VBAT could drop below operating limits or be removed during operation a hard fault could occur at any RTC access during operation.

In such a case the hard fault could be used to signal the problem. The hard fault handler can be modified to recognise that a RTC access caused the fault and allow recovery (eg. by setting a flag in the RTC code that avoids its further use and signals the state to the outside world). This is something that I have never actually done any may require a handler that can analyse the source of access and then manipulate the stack to return to a location just before the failed access that checks the flag again.

You are correct that measuring the battery voltage using an ADC is also a possible method, which could then also give a warning when the battery voltage is getting close to failing.

Regards

Mark

[priyankb]

Hi Mark

Thanks for clearing some concepts.

Meanwhile I tried using VBAT register file. I read in reference manual that it maintains value stored even after reset since it is powered by VBAT.

I tried writing & reading some value in them to check if they are same, if not VBAT is absent. But  I learned that you cannot even access them if VBAT is not present.

I guess the simplest and the cleanest way is to use an ADC.

[priyankb]

Hi Mark

Thanks for clearing some concepts.

Meanwhile I tried using VBAT register file. I read in reference manual that it maintains value stored even after reset since it is powered by VBAT.

I tried writing & reading some value in them to check if they are same, if not VBAT is absent. But  I learned that you cannot even access them if VBAT is not present.

I guess the simplest and the cleanest way is to use an ADC.

[neilporven]

Thank you Mark.

I tested the following and sure enough it does check out!  

If I debug the board without the backup battery, the compilation fails into a  the vector (PE_DEBUGHALT()) it gets

trapped in there.  The minute I place the backup battery, then the compilation is successful and the breakpoint

PE_low_level_init(); is reached ready for execution.

Freescale should write this in somewhere????

[nitinharish]

mjbcswitzerland​, I am trying to use IRC48M as my system clock source (K64, using MQX4.1.1, no PE), have done essential changes to MCG_C7 and PLL/FLL dividers. I am facing exact same issue as you did with RTC as your clock source i.e. spinning forever in the following statement:

while((MCG_S & MCG_S_IREFST_MASK) != 0x00U) { /* Check that the source of the FLL reference clock is the external reference clock. */

I think this issue has deeper reason.

Did you get to run with IRC48M successfully or you just tried RTC ?

Let me know.

Thanks and Regards

Nitin

[nitinharish]

mjbcswitzerland​ as usual your post was helpful, specially the section about IRC48M in this webpage: µTasker MCG Configuration Support

Atleast now I am out of the woods, no more waiting infinitely for PLL to use Ext Ref clock as source. (I also had kinetis-64 part where IRC48M had to enabled via USB module)

Although after a little run, I get interrupt from unknown source.

[mjbcswitzerland]

Nitin

I also lost some time with the IRC48M as clock source even though I knew about the issue - unfortunately I forgot about it again and, since this is (illogically) not counted as a device errata, one needs to get a bit lucky and stumble on the reason in the crystal-less USB application note.

I don't expect that your following interrupt problem is releated, unless you have a bus clock set too high (like Flash clock).

As noted in the description in the link, there are restrictions when used together with USB, however I have successfully implemented automatic detection and workaround for it in both direct IRC48M and PLL IRC48M modes - FLL IRC48M modes don't need any workaround for USB to be used due to the inherent nature of the FLL being able to survive (temporarily) removing its input reference clock.

Regards

Mark

Kinetis: µTasker Kinetis support

K64: µTasker Kinetis FRDM-K64F support  / µTasker Kinetis TWR-K64F120M support

For the complete "out-of-the-box" Kinetis experience and faster time to market

[nitinharish]

As always you are right mjbcswitzerland​.

I have resolved all my issues (interrupt was related to an update in IAR compiler which caused FPU selected in my BSP by default).

And I agree with you, enabling IRC48M via USB module (only for "some" Kinetis K-64 devices) should be an errata and should be traceable via Part Number

My end goal is to use 32KHz IRC as my system clock (working on it)

[Hui_Ma]

Hi Mark,

K64 support using external RTC clock (32.768KHz) crystal as clock source for FLL, then generate system clock and bus clock.

Please refer my attached KDS project and I output the Flexbus clock at PTC3 pin and get the 48MHz clock at scope.

My tested KDS version is 2.0.0

Processor Expert for Kinetis Design Studio

Version 1.0.0

Build: RT6_b1444-1070

FRDM-K64F  board.

Wish it helps.

Have a great day,
Ma Hui

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

[mjbcswitzerland]

Hi Ma Hui

The version that you generated works on my board but the one that I generate doesn't. I didn't see a difference in version so there must be a setting that is not identical somewhere causes a different result. I see that my code gets stuck when trying to switch a clock but yours doesn't check whether it switched correctly so is not identical.

However I have been able to conclude a few things:

- Essentially I was being too careful and moving from FEI to FEE via FBI, which was not achieving the switching from FBI to FEE. I will study this more later but for the moment simply do the FEI to FEE switch in a similar way.

- I realise that the FLL is in fact much more robust than originally anticiated and will accept brute-force changes without any issues. In fact, once it is operating, one can disable the RTC and it will continue oscillating on its own (presumably at its natural frequency and there are no glitches or such which disturb the processor). Furthermore, one can switch to it even when "illegal" inputs are applied (missing input clock or input clock out or range), whereby I suppose that the fact that it continues oscillating allows this to be possible.

So basically, one can do the configuration with just 3 instructions and not worry about the fact that during short periods the clock may be unreferenced - due to its inherent nature.

Looking at the PE code that you generated I see that it enables the main oscillator (OSC0) which is unnecessary and possible unwanted (?)

Once I return to further state changes and can't achieve one that should be legal I will maybe start a new topic.

Thanks.

Regards

Mark

[mjbcswitzerland · Accepted solution]

Hi All

In the meantime I have an explanation why the configuration doesn't "always" work.

See the following code in CPU_init.c (used by PE, or generated by PE (?))

  /* System clock initialization */

#if STARTUP_RTCOSC

  /* SIM_SCGC6: RTC=1 */

  SIM_SCGC6 |= SIM_SCGC6_RTC_MASK;

  if ((RTC_CR & RTC_CR_OSCE_MASK) == 0u) { /* Only if the OSCILLATOR is not already enabled */

    RTC_CR = (uint32_t)((RTC_CR & (uint32_t)~(uint32_t)(RTC_CR_SC2P_MASK | RTC_CR_SC4P_MASK | RTC_CR_SC8P_MASK | RTC_CR_SC16P_MASK)) | (uint32_t)STARTUP_RTC_CR_SC_VALUE);

    RTC_CR |= (uint32_t)RTC_CR_OSCE_MASK;

    RTC_CR &= (uint32_t)~(uint32_t)RTC_CR_CLKO_MASK;

  }

#endif

Notice that the final instruction executed when the oscillator is not enabled is to clear the CLKO mask. If this mask is set the 32.768kHz generated by the RTC is not actually availabe as physical output for use by the MCG, in which case the attempted switch to the external clock input to the FLL 'will' hang.

The probem is that if the RTC on the board is already operating and has the mask set (which was the case when I initially tested) the oscillator initialisation will be skipped and the mask left on, with the result that the clock initialisation fails (hangs).

This means that the CLKO mask reset should be performed unconditionally so that new code loaded to a board that has the RTC already configured can't fail. It should therefore actualy be outside of the if ()

Below I have added the CLKO mask switch to the MCG diagram since it is otherwise not seen and can result in unnecessary study being required in such cases.

Regards

Mark

[mjbcswitzerland]

Hi All

Note that there is a practical dicussion of varous details of the MCG, along with possible pit-falls at http://www.utasker.com/kinetis/MCG.html

Regards

Mark

[chadwilliams]

Hi Mark, thanks for the explanations,

I was in the process of looking into FLL operation with a 32KHz external so your article was good timing...

From what I have read and in working briefly with processor expert I have found its not possible to configure the FLL

to produce clock frequencies below  20.97152MHz and so its not possible to have the device operating at lower frequencies

in order to reduce power consumption in continuous operation.  I have worked with MSP430 devices in the past

and they have a DCO which can be programmed to ideal frequencies for serial communication such as 7.3728MHz and 14.7456MHz

and the low power modes that MSP430 provide make conserving battery power a relatively simple task. I will be seeking

to achieve similar power optimization with the newer Kinetis devices.

regards

Chad

[mjbcswitzerland]

Chad

It is correct that the lowest FLL output frequency (and MCGOUTCLK) is 20.97152MHz due to the lowest FLL factor (multiplier) being x640.

However the system and bus clocks can be divided by 1..16 to give actual working clocks down to 1.31MHz.

You will get absolutely lowest power consumption by not using the FLL but instead clocking directly from the 32kHz clock but that will of course be very slow and be unsuitable for general UART speeds - also I didn't manage to get any of my debuggers to handle this speed.

Regards

Mark

[chadwilliams]

I was able to get the K24 running in FEE mode using the external RTC oscillator. I used the Processor Expert to generate the code.

I also learned that the VBAT power pin must be connected to a power source, so if an RTC backup battery is not present VBAT must be supplied via a diode preferably.

If no power source is present on VBAT , the device will present a hardfault when the external RTC is selected.

[mjbcswitzerland]

Hi Chad

I had a case where PE didn't generate working code because the RTC was already configured and it failed to enable the 32k output clock - then hung forever. The improvement is in the previous post.

PE generates a complete state machine and so it takes about 1'000 (a little exagerated but it takes a long time to step the code) instructions to actually set up the MCG, whereby only a handful are needed:

	POWER_UP(6, SIM_SCGC6_RTC); // enable access to the RTC
	MCG_C7 = MCG_C7_OSCSEL_32K; // select the RTC clock as external clock input to the FLL
	RTC_CR = (RTC_CR_OSCE); // enable RTC oscillator and output the 32.768kHz output clock so that it can be used by the MCG (the first time that it starts it can have a startup/stabilisation time but this is not critical for the FLL usage)
	MCG_C1 = (MCG_C1_CLKS_PLL_FLL | MCG_C1_FRDIV_RANGE0_1 & ~MCG_C1_IREFS); // switch the FLL input to the undivided external clock courcse (RTC)
	SIM_CLKDIV1 = (((SYSTEM_CLOCK_DIVIDE - 1) << 28) | ((BUS_CLOCK_DIVIDE - 1) << 24) | ((FLEX_CLOCK_DIVIDE - 1) << 20) | ((FLASH_CLOCK_DIVIDE - 1) << 16)); // prepare bus clock divides
	while ((MCG_S & MCG_S_IREFST) != 0) {} // wait until the switch to the external clock source has completed
	MCG_C4 = ((MCG_C4 & ~(MCG_C4_DMX32 | MCG_C4_HIGH_RANGE)) | (_FLL_VALUE)); // adjust FLL factor to obtain the required operating frequency

PE also enables the second oscillator, which is not necessary and possibly consumes additional and unnecessary power.

Therefore PE is not fool-proof and it is worth analysing what it does and possibly correcting it a little.

If the VBAT of the K64 is not connected the RTC will also not work and any attempt to access it will result in a hard-fault. This was also found in a product development that I was involved with so it is a "general" requirement.

Regards

Mark

Kinetis: µTasker Kinetis support

K64: µTasker Kinetis FRDM-K64F support  / µTasker Kinetis TWR-K64F120M support

For the complete "out-of-the-box" Kinetis experience and faster time to market