Using external RTC module clock config in MCUXpresso

[Anonymous]

Hello,

I am using MCUXpresso and it's config tools. Currently my target is MK64FX MCU Teensy 3.5 board but I am using examples from FRDM-K64F board . I configured Teensy board clocks to max 120MHz and to use RTC module with external 32MHz oscillator. The imported project rtc_func from FRDM-K64 board examples functions as described on my Teensy but I think that example is not using RTC module / external oscillator, but rather internal source MCGIRCLK.

Can somebody point me to a right clock configuration used with Clock Config tool which routes true RTC clock from RTC module to be used for any RTC application?

[Anonymous]

Mark, unfortunately you are absolutely right in your conclusion :smileysad: The MCUXpresso as a tool is probably the best tool for the development in terms of good overall architecture and integration of the toolchain, I was glad to discover it...but ... evidently has loose unfinished ends... might not be ready for a large project...

I don't stuck waiting for a particular solution (many tasks at hand running in parallel), yet you are right - there is no good reason for such a powerful tool as Clock config tool to not complete the routing of the real time external oscillator to all the internal on-chip circuits.

BTW, STM32CubeMX completes this job easily in a graphical config.. I did not even need to study documentation on that....

[Robin_Shen]

The RTC module can not select the internal source MCGIRCLK, EXTAL32 is the internal clocks of RTC.

The RTC module use external 32.768KHz crystal. (Teensy 3.5 also connect 32.768KHz crystal at EXTAL32 and XTAL32 pins.)

I import the rtc SDK_2.4.0_FRDM-K64F example into MCUXpresso IDE.
Then open the Clocks view of ConfigTools, I can see the Inactive shown at RTC although the RTC_CR[OSCE] has been enabled.

There is a NOTE in MCUXpresso_IDE_ConfigTools_User_Manual, which can be used to explain.

The SIM_SCGC6[RTC] controls software access and interrupts to the RTC module, the Clocks of ConfigTools did not enable it.

It was enabled in RTC_Init() function,you can find it in rtc.c files.

Best Regards,

Robin

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

[Anonymous]

Robin, do your references to the RTC_Init() code indicate that MCU internally uses RTC module with it's 32kHz oscillator for all the real time related clocks?  Despite the config tool showing the RTC32kHz  "inactive" ?

[Robin_Shen]

Yes.

That example is not using RTC module / MCGIRCLK.

After close MCGIRCLK by clear MCG_C1[IRCLKEN], that example can still work.

Best Regards,

Robin

[Anonymous]

I don't understand the purpose of the "RTC" code example for K64 family if it does not use Real Time RTC module at all............

Is there any example code for K64 MCU of using true real time with RTC module active ? Can you point to such?

[mjbcswitzerland]

Vladimir

I have the impression that your problem hasn't been understood by Robin and so things are getting confused, or maybe I didn't understand (?). But, assuming that you simply want to use the RTC clock source as input to the FLL to generate a high frequency clock for the core (bus, flash etc.) it is quite simple [7 lines of c-code] and doesn't really need script-kiddy tools:

Doing it with good old fashioned engineering (whïch looks to save days of development time and costs in this and many such instances):

    POWER_UP_ATOMIC(6, RTC);                                             // enable access to the RTC
    MCG_C7 = MCG_C7_OSCSEL_32K;                                          // select the RTC clock as external clock input to the FLL or MCGOUTCLK
    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 source (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 ready for the final operating frequency
    while ((MCG_S & MCG_S_IREFST) != 0) { }                              // wait until the switch to the external RTC 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
‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

(for revision 2 silicon - rev. 1 does it slightly differently).

Regards

Mark

P.S. If you want to (also) use the RTC for time date etc. in the application check out
http://www.utasker.com/docs/uTasker/uTasker_Time.pdf where complete Gregorian calendar, time zone management, daylight-saving, alarms and more is already available....

[Anonymous]

Indeed, there is probably a miscommunication . Usage of RTC module in MCU implies a "true" timer synced with RTC oscillator. If code is using internally generated 32.768khz - this is nothing to do with demonstration of the RTC module of K64, whence the code example to me is like a "fake".

ABout your example - do you realize that your code implies knowledge of the MCU internal registers? Plus library associated with it (is it utasker routines?)  I was working like this 40 years ago, at the dawn of this age:)

If I were to learn the internal registers of MCU for all my needs in the current project I would drop it :smileyhappy:  For my current project I need luxury of HAL :smileyhappy:

[mjbcswitzerland]

Vladimir

All such C-code needs knowledge of internal registers.

As mentioned previously, the HAL in uTasker needs the user to just specify

RUN_FROM_RTC_FLL

and the (shown) code is present as required. This is not more difficult than setting up a number of paths in a graphic tool, which also generates the 'same' code for actual use (as long as "all" paths are set up correctly and the code that it generates is indeed correct because it was also written by someone and linked to the tool). The user thus needs to know what he/she "wants" (as you do) but not need to know the registers involved (unless it interests him/her).

In the 7-line code case shown, the user fine tunes the desired frequencies with these following additional defines (which have a default set if the maximum frequencies are already good) - the actual values in the final registers are 'generated' at compile time to give the user requirements (or errors are generated when the user tries something out of specification):

#define FLL_FACTOR           2929     // use FLL (factors available are 640, 732, 1280, 1464, 1920, 2197, 2560 and 2929)
#define FLEX_CLOCK_DIVIDE    2        // 96/2 to give 48MHz
#define FLASH_CLOCK_DIVIDE   4        // 96/4 to give 24MHz
#define BUS_CLOCK_DIVIDE     2        // 96/2 to give 48MHz
‍‍‍‍

Regards

Mark

[Anonymous]

All such C-code needs knowledge of internal registers.

and then

The user thus needs to know what he/she "wants" (as you do) but not need to know the registers involved (unless it interests him/her).

if I got it right your library also gets "present as required" as you said -  so then which one statement is correct, 1st or the 2nd?  My point is I cannot afford to learn through 1800 pages of the MCU reference manual for all the functions I need from MCU. The graphic tool if done right allows to intuitively choose the needed configuration. May be your library allows that too... but any solution which requires my knowledge of internal registers is not any more acceptable in this age of embedded apps (I left this method in my past)

[mjbcswitzerland]

Vladimir

What I mean is that whoever writes the actual code that users put in their product "needs" to know about the registers - whether it is the person preparing the code that is pieced together with a graphical tool or whether its is a HAL library. The idea is to add an abstraction layer so that the application developer can concentrate on the application and not the underlying details (although embedded programmers will always be working closer to the HW than an application programmer on a PC platform, for example).

Whether your preferred method is to click boxes in a GUI or select defines is your choice but both will generally work. The question is however which works better (also which gives greatest choice and better code quality for the actual project in hand)?

I am not yet convinced that you have found your luxury solution because I see that after one week of work (or waiting) you don't yet have a solution for clocking from the RTC while I have one by commenting in or out a single define in a header file. (Also in a free open source reference that is available for everyone willing to invest a few minutes to download it).

I'll do another test:
- I just took the project and modified the same RTC setting for a TEENSY-3.5 (your HW).
- Then I did a couple of other configurations to add a FAT file system with the SD card, plus a command line interface on the USB interface (USB-CDC) as composite with USB-MSD so that the SD card appears as an external hard drive when connected.
- I build it with GCC and simulated it in Visual Studio to check some basics (see screen shot below where the simulation confirms USB operation, the clock speeds and the SD card pin out
- I have attached the HEX file that can be loaded to a real TEENS 3.5 board for anyone who wants to try it.

I don't actually have a TEENSY 3.5 so I can't test (and be 100% sure) but I do expect it to operate with a high probability (there are various Teensy 3.5 and Teensy 3.6 users of the project who have confirmed full functionality and especially the uTasker serial loader is used by many Teensy 3.1, Teensy 3.5 and Teensy 3.6 projects or products derived from them).

Furthermore, if I decide to do the same on a teensy 3.6 (K66) I can change a single define (TEENSY_3_5 to TEENSY_3_6) and the complete HAL will switch to the other chip and HW (I can do the same for about 60 standard Kinetis boards/chips too). I timed the work to be under 5 minutes so if it were to fail I would have a little reserve to debug something if necessary.

In comparison, I find the abstraction power much greater than the graphical tools which are limited and need to be repeated for each processor type. Also the library HAL has a much better and higher abstraction level - for example a user can run code on any chip, on any UART (UART, LPUART, with INTMUX, or whatever just by specifying its interface number, meaning porting for each new chip is a thing of the past).

Additionally, remember that the (complete chip) configuration that your are presently doing is something that can generally be done in a few minutes (by both methods if they work) and represents only maybe <0.01% or real product development effort. What baffles me on a daily basis (I consult many Kinetis product developments) is that a tool set is often chosen based on the fact that it may be easier to set up the project (an almost insignificant part of the overall time and cost), and then the entire development may suffer because the rest that was inherited was often un-maneagable and unreliable.

Finally, you are absolutely right that today's processors are much more complex and having good tools (libraries, simulator or whatever) is important to getting a job done efficiently without needing to know all details under the bonnet. However, I find that a week to set up a clock is something definitely totally unacceptable in this age (or any age) - something is presently very wrong and needs addressing urgently...

Regards

Mark

[Robin_Shen]

Sorry, my last reply may be misunderstood!
I just want to tell you that RTC example is using 32kHz external crystal with internal RTC oscillator, the connection between 32kHz external crystal and K64 is same as Teensy 3.5 board.(Both FRDM-K64F and Teensy 3.5 connect 32kHz external crystal at EXTAL32 and XTAL32 pins.)

Due to you said "but I think that example is not using RTC module / external oscillator, but rather internal source MCGIRCLK."
In fact that example is using RTC module / external 32kHz crystal with internal RTC oscillator, not the internal source MCGIRCLK.

Best Regards,

Robin

[Anonymous]

Robin, how I suppose to understand your message earlier saying "That example is not using RTC module / MCGIRCLK."  ? You reversed it...

How does the "Clocking Diagram" picture in this post relate to the RTC code example we discuss? Where did you get this diagram from ?

THe hardware diagrams show hardware connections of the oscillator crystals to the respective boards FRDM-K64 and another Teensy 3.5 . I am well aware of this. But the subject here is whether software examples are indeed using this hardware RTC feature.  You know hardware feature might be or might not be used in the software. THat's why we need a code example showing such usage. I don;t see anything in your post that points to such configuration of the software driver.

[mjbcswitzerland]

Hi Vladimir

The uTasker project (free open-source) supports also the Teensy 3.5 (and allows it to be simulated) so you can download that and use it as reference in order to correct or work out how to do things in the environment you need to use (it aso works in MCUXpresso).
To run the K64 from the external RTC input you simply choose the define
RUN_FROM_RTC_FLL
which enables the RTC oscillator and routes its input to the FLL and sets the highest FLL output frequency of 96MHz - the simulation screen shot below shows the exact frequencies achieved, whereby USB is not functional with this configuration unless used as device in crystal-less mode.

General practical explanation of MCG: http://www.utasker.com/kinetis/MCG.html
Teensy 3.5 reference: http://www.utasker.com/kinetis/TEENSY_3.5.html

Regards

Mark

Kinetis: http://www.utasker.com/kinetis.html
Kinetis K64:
- http://www.utasker.com/kinetis/FRDM-K64F.html
- http://www.utasker.com/kinetis/TWR-K64F120M.html
- http://www.utasker.com/kinetis/TEENSY_3.5.html
- http://www.utasker.com/kinetis/Hexiwear-K64F.html

Free Open Source solution: https://github.com/uTasker/uTasker-Kinetis
Working project in 15 minutes video: https://youtu.be/K8ScSgpgQ6M

For better, faster, cheaper product developments consider the uTasker developer's version, professional Kinetis support, one-on-one training and complete fast-track project solutions to set you apart from the herd : http://www.utasker.com/support.html

[Anonymous]

Thank you Mark for your input -I'll research that library. Please let me know if utasker uses the  pin_mux.c/h, clock_config.c/h and peripherals.c/h files  to be able to use it with MCUXpresso config tool?

[mjbcswitzerland]

Vladamir

No, these files are not shared. It is easier that using the config tool because it just needs a single define to control all and verifying the real code is fast in its simulator.

Since it makes sense to know some details rather than relying on a black box generating the correct code (which it may or may not do) the uTasker project practices understanding the principles and using engineered code. See the following for a practical MCG discussion:
http://www.utasker.com/kinetis/MCG.html

Regards

Mark