Using RTC with KDS, PE and MQX

[davepfaltzgraff]

My interest is merely in using the RTC as a Date/Time source and be able to read the current value when needed.. While setting this up, the PE insisted that I need an interrupt handler to keep MQX happy.

If I just put a RTC_DRV_GetDatetime() in the code and print the results, the time does not increment. Figuring that I might need to call RTC_DRV_init(), I put it in there and it appears that I end up in the DefaultISR infinite loop.

Note that the interrupt routine rtcTimer1_irqHandler() has a NULL body and that the interrupt for RTC_Seconds is disabled in PE.

How can I use the RTC as just that in an MQX environment?

Note that this is on a FRDM-K22F board.

[davepfaltzgraff]

There are two issues here. The first is that in order to get the RTC running, there must be a call to RTC_DRV_SetDatetime() to kick off the counters. This poses an interesting problem for systems that use a battery to maintain the time. This is an issue for later.

The other issue is that according to PE MQX "requires" the rtcTimer1_irqHandler(). Since this application is not interested in that interrupt, I merely put in a call to INT_SYS_DisableIRQ(g_rtcIrqId[0]) to disable it on the first call. This is an issue that the PE/MQX folks need to address.

If the application is interested in this interrupt, then there must be a means of acknowledging it to prevent further interrupts until the time has expired.

It is interesting to note that while stepping through the code, there is a call to INT_SYS_EnableIRQ(g_rtcSecondsIrqId[instance]) in RTC_DRV_Init() which implies to me that the interrupt gets enabled even though PE stipulates that the routine should not be written. This is confusing.

[soledad]

Hello David,

If you are using MQX for KSDK then please check the below thread and let me know if this helps!!

OSA_TimeDelay hanging on TWR-K64F120M | Freescale Community

If you are using MQX "classic" you can RTC example at the path: C:\Freescale\Freescale_MQX_4_1_FRDMK22F120M\mqx\examples\rtc

Attached to this, you can find the readme example

Have a great day,
Sol

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

[davepfaltzgraff]

The issue in the referenced thread on OSA_TimeDelay is different from mine.In the OSA_TimeDelay case, the user just wants some fixed delay selected by the program. In my case I am trying to use the hardware RTC to provide a date/time stamp. This is the purpose of an RTC in an embedded system that may be turned off or in low power state for extended periods of time and there is no external source for date/time information. Consider, for example, a system that is used for logging environmental parameters in a remote location that is solar powered. If the solar power fades, and thus power is lost to the base system, when it returns the system must have some knowledge of the date and time. The on-board RTC, which has it's own Lithium cell. will provide that information within the accuracy of the 32.768KHz oscillator.

As I mentioned in my own reply, I was able to get the RTC running by writing a time to it. However, in the example provided above, if I can't get the RTC to work without writing to it, what purpose is the Lithium cell? As in writing some value to the RTC, I have lost the information that it contained.

The answer to this is probably buried in the hardware internals. I am presuming that there is a way to find out that the RTC is powered externally and is running. In this case, there is no need to write to the RTC to get it running. I am postponing further investigation until such time that this functionality is needed.

I hate to say it, but if the Freescale RTC doesn't preserve the date and time as expected, there are plenty of others on the market that do. So, this is not a show stopper.

[DavidS · Accepted solution]

Hi David,

Your observation peek my interest to run a test on our KDS2.0.0/demo/rtc_demo project.  Sorry this is not using PE and MQXLite but it might provide direction for you to enable it and also provide others that would want this baremetal capability to test with on the FRDM-K22F120M.

If you do implement with PE+MQXLite please post it back here.  If you don't get to it, I'll try when I have additional time.

My FRDM-K22F120M didn't have battery so I wire wrapped one on and cut track under (backside) J21 jumper.

This allows VBAT to operate the RTC if the USB debugger is not connected.

My code doesn't use ADC to check if there is VBAT.  It assumes VBAT is valid/present.

When you run code for the first time, the RTC is not enabled.  Code will do that and give it an initial date/time.

Use the terminal interface to set the correct date/time.

Once this is complete you can disconnect the USB debugger cable from FRDM-K22F120M and date/time will be maintained.

Be sure to have disconnected or exited your VCOM terminal interface before re-connecting the USB debugger cable to allow VCOM enumeration.

Once USB debugger cable re-connect some time later, re-connect your terminal window and hit Enter to see terminal options and also at top it will display the current date/time.

My example Terminal output:

Serial port COM15 opened
1
Current datetime: 2014-04-30 14:00:03


Please choose the sub demo to run:
1) Get current date time.
2) Set current date time.
NOTE: Accuracy maybe affected by a few seconds if RTC counter clock is not 32KHz.
3) Alarm trigger show.
NOTE: Alarm will be delayed if RTC counter clock is not 32KHz.
4) Second interrupt show (demo for 20s).
NOTE: Interrupt will be delayed if RTC counter clock is not 32KHz.
5) Set RTC compensation.


Select:2
Input date time like: "2014-04-22 16:40:00"
2015-02-18 14:47:00
Current datetime: 2015-02-18 14:47:00


Please choose the sub demo to run:
1) Get current date time.
2) Set current date time.
NOTE: Accuracy maybe affected by a few seconds if RTC counter clock is not 32KHz.
3) Alarm trigger show.
NOTE: Alarm will be delayed if RTC counter clock is not 32KHz.
4) Second interrupt show (demo for 20s).
NOTE: Interrupt will be delayed if RTC counter clock is not 32KHz.
5) Set RTC compensation.


Select:1
Current datetime: 2015-02-18 14:47:01


Please choose the sub demo to run:
1) Get current date time.
2) Set current date time.
NOTE: Accuracy maybe affected by a few seconds if RTC counter clock is not 32KHz.
3) Alarm trigger show.
NOTE: Alarm will be delayed if RTC counter clock is not 32KHz.
4) Second interrupt show (demo for 20s).
NOTE: Interrupt will be delayed if RTC counter clock is not 32KHz.
5) Set RTC compensation.


Select:
Serial port COM15 closed
Serial port COM15 opened
1
Current datetime: 2015-02-18 14:48:11


Please choose the sub demo to run:
1) Get current date time.
2) Set current date time.
NOTE: Accuracy maybe affected by a few seconds if RTC counter clock is not 32KHz.
3) Alarm trigger show.
NOTE: Alarm will be delayed if RTC counter clock is not 32KHz.
4) Second interrupt show (demo for 20s).
NOTE: Interrupt will be delayed if RTC counter clock is not 32KHz.
5) Set RTC compensation.


Select:

Regards,

David

[davepfaltzgraff]

Hi Dave,

I was unable to get your code to compile. Just FYI, I unzipped it to C:\Projects\DES\rtc_func_rdmk22f\... and imported it into KDS. When I tried to compile, I got was a bunch of

====

No rule to make target `C:/platform/utilities/src/fsl_debug_console.c', needed by `utilities/fsl_debug_console.o'

====

However, I did look through your code and saw that you had a call to RTC_DRV_IsCounterEnabled(0) to see if the clock was already running. That's the link I was looking for.

I figured that there had to be such a test, but, since I was not at that point in my project, I hadn't dug deep enough into it.

To continue the discussion we had on another thread, the attached file is two tasks running under MQX. The first flashes the three LEDs in "number order" while the second prints out the date/time based on the internal delay function. As it was originally written, I could not get the RTC to run without writing something to it. So, the flash LED task wrote something to kick it off. With the test you showed me above, the code in the flash LED task (or move it over to where it belongs in the print time task) could easily be modified so that if the clock was already running it would not be (re)initialized.

By the way, I noted that the RTC_DRV_Init(0) routine seems to set the date to 1970-01-00 which is an illegal date. Most of the RTC devices (I2C, etc.) won't accept this value. To me this is a non-issue, but you may want to pass it on to whoever is responsible for the code.

Thanks again for your help.