iMX28 RTC clock and 32kHz oscillator

cancel
Showing results for 
Search instead for 
Did you mean: 

iMX28 RTC clock and 32kHz oscillator

Jump to solution
679 Views
RoboTech
Contributor III

I have a custom design where I want to run the RTC from an external 32.768kHz crystal

So I modified the mxs-rtc driver this way:

@@ -246,6 +246,11 @@ static int mxs_rtc_probe(struct platform_device *pdev)

            (hwversion >> 16) & 0xFF,

            hwversion & 0xFFFF);

+    // enable 32kHz oscillator in power off mode, source RTC with 32kHz clock

+    __raw_writel(BM_RTC_PERSISTENT0_XTAL32KHZ_PWRUP |

+            BM_RTC_PERSISTENT0_CLOCKSOURCE,

+             rtc_data->base + HW_RTC_PERSISTENT0_SET);

+

     rtc_data->rtc = rtc_device_register(pdev->name, &pdev->dev,

                 &mxs_rtc_ops, THIS_MODULE);

     if (IS_ERR(rtc_data->rtc)) {

This apparently worked on another custom design we made. I could see the 32kHz oscillation on a scope even after poweroff and measured roughly 11uA consumption from the battery.

Now this is acting strangely on a similar custom design. Sometimes I can't see any oscillation with a scope, but I can tell the oscillator has been turned on, because I see a positive DC level on the XTAL pins roughly at 500mV. Sometimes the probe seems to help the oscillation, which starts slowly but it's not stable. Sometimes it seems the opposite: as soon as I connect the probe the oscillation seems to shut off.

The weird fact is that the "date" command still works in all scenarios, whatever clock source I set in the RTC and whether or not the external crystal is populated. How can this happen?

Running "date" in a loop with 1 second delay shows that time is correclty updated.

Where does the "date" command get the current time of day? Does the RTC automatically fall back to the 24MHz clock source if the 32kHz is not found oscillating?

Any clues?

Thanks,

Paolo

Labels (2)
Tags (3)
0 Kudos
1 Solution
199 Views
RoboTech
Contributor III

I will answer my own questions. Little bit of research showed that the "date" command does not use the RTC clock. The system time is updated independently.

The command to use is "hwclock". This showed indeed that the 32kHz oscillator was running. The time/date is preserved after poweroff.

The scope probe causes problems to the oscillator. The time displayed by "hwclock" stops when I connect the probe. This is somewhat expected, even if I rarely had this kind of problems by simply probing crystal pins. I suspect something wrong with the design.

Interesting note: using the "memtool" command to switch the RTC clock source does not work and it leads to severe issues at next boot. I tried switching back to the 24MHz clock with: "memtool 80056060=100", but this only stopped the RTC count and turned off the 32kHz oscillator (I read a 0V on crystal pins). So I issued a "reboot" command, but the boot process stopped just after the bootlets give control to the kernel. The device does not seem to draw more current than usual boots, but it is stuck. I have to remove battery power to recover, external "RESET" pin does not help either (it does power down the device, but the next boot still hangs).

Hope this helps somebody else.

Paolo

View solution in original post

0 Kudos
1 Reply
200 Views
RoboTech
Contributor III

I will answer my own questions. Little bit of research showed that the "date" command does not use the RTC clock. The system time is updated independently.

The command to use is "hwclock". This showed indeed that the 32kHz oscillator was running. The time/date is preserved after poweroff.

The scope probe causes problems to the oscillator. The time displayed by "hwclock" stops when I connect the probe. This is somewhat expected, even if I rarely had this kind of problems by simply probing crystal pins. I suspect something wrong with the design.

Interesting note: using the "memtool" command to switch the RTC clock source does not work and it leads to severe issues at next boot. I tried switching back to the 24MHz clock with: "memtool 80056060=100", but this only stopped the RTC count and turned off the 32kHz oscillator (I read a 0V on crystal pins). So I issued a "reboot" command, but the boot process stopped just after the bootlets give control to the kernel. The device does not seem to draw more current than usual boots, but it is stuck. I have to remove battery power to recover, external "RESET" pin does not help either (it does power down the device, but the next boot still hangs).

Hope this helps somebody else.

Paolo

View solution in original post

0 Kudos