RTC driver for Kinetis.

[SpaceCoaster]

Hi,

Attached is an RTC implementation for Kinetis. It is incomplete due to the difficulty of mapping the RTCDateTime in 3.0 to the 32 bit time in seconds format used by the RTC device.

As an additional oddity it follows the example from https://community.freescale.com/docs/DOC-94734 to configure the 8MHz clock to be the source of the 32kHz clock needed for the RTC. The example describes using a physical wire to connect PTC3(CLKOUT) and PTC1(RTC_CLKIN). I removed the wire and it still works! However I needed to leave PCT1 configured as RTC_CLKIN but disconnected to make it work.

I also found a missing definition for pal_lld_setpadmode() for the KL2x and that is in a separate patch.

Your suggestions are much appreciated.

Thanks,
Derek

[SpaceCoaster]

The attached patch connects up the already existing implementation of pal_lld_setpadmode() for the KL2x devices. It looks like the PAL driver could be made common between the Kinetis devices.

This looks like it was just an oversight and I will apply the patch later if no one objects.

[utzig]

I suggest that you commit the PAL changes. Will look into the RTC code later.

[fpga_comp]

>However I needed to leave PCT1 configured as RTC_CLKIN but disconnected to make it work.
The signal is probably getting coupled by stray capacitance. It can pick up all kind of noise etc.

A comment about the pal_lld_setpadmode():
I found the modes setting too restrictive for my application. There are lots of combination that are not available.
I used the upper reserved bits of the PCR register in my own K22 fork for setting the corresponding PORT registers
and simply use the PCR bitmask to set the PCR.

The following is the partial code for some of the settings for my I/O.

Code: Select all

IOPORTB,
{
  /* PTB0*/ PORTx_PCRn_MUX(2)|  // I2C_SCL - open drain
                 PIN_OPENDRAIN,
                        :
IOPORTD,
{
  /* PTD0*/ PIN_GPIO_OUTHIGH,    // SPI_CS0
  /* PTD1*/ PIN_GPIO_OUTLOW,       // CONFIG_EN
       
  /* PTD2*/ PIN_GPIO_INP|            // KBD_CLK - open drain, pull up
                 PIN_PULLUP|         // IRQ falling edge
                 PIN_OPENDRAIN|
                 PORTx_PCRn_IRQC(0x0a),
                       :


[SpaceCoaster]

>However I needed to leave PCT1 configured as RTC_CLKIN but disconnected to make it work.
The signal is probably getting coupled by stray capacitance. It can pick up all kind of noise etc.

I wondered if that was the case so I turned off the 32kHz output on PCT3 and it still carried on working. Whatever the stray signal is it seems to be 32kHz. I probed around with a scope and I didn't see any 32kHz for it to latch onto. Perhaps it is being connected internally somehow.

[colin]

Awesome progress Derek.

Will this support a 32.768 kHz crystal on the FRDM-KL25Z board?

I replaced the stock 8 MHz crystal with a 32.768 kHz crystal on about half my FRDM-KL25Z boards, so I can use the FLL for the system clock (faster wakeup and lower power consumption than using 8 MHz+PLL, also you can directly use the RTC and keep the clock running in VLPS low power mode etc.).

[SpaceCoaster]

Yes, I think it will use that crystal, although I don't know how to configure it. I did find some information on that setup.

The set time/get time code still needs to be written. The current 3.0 RTC seems to be a bit STM32 specific.

When I work on completing this and making it work with the K20D50M, which does have an additional 32kHz crystal, we can try to get it working on your tricked out board(s).

[Giovanni]

The RTC data/time formats are meant to be generic, how are those STM32 specific?

Giovanni

[SpaceCoaster]

Three "reasons".

0. When did the Epoch become 1980!!!

1. rtcSetAlarm() and rtcGetAlarm() are only declared when STM32_RTC_NUM_ALARMS > 0

2. Lastly, and the only real one, for the STM32 RTCv2 driver it is really easy to map the DateTime onto the registers. For a processor using uint32_t it is not completely trivial.

A reversible and monotonic mapping is required from/to DateTime and uint32_t. Leap years would have to be taken into account to handle alarms which span any February 29ths. The alarm function could be passed a DateTime. It would be converted into a uint32_t, subtract the current time and use the delta.

I have a narrow view of Unix time in seconds being the real true time and DateTime as being just some vaguely correlated display format. I guess I just conceded.

Cheers,
Derek

[SpaceCoaster]

Hmmm, DST changes at between 2AM and 3AM in the US. Some nights have 2 x 2:30AM, some nights have none. Alarms which span DST changes would be tricky.