RTC alarm not working

[mipek]

I got my Watchy today but to my surprises the time is not updating. Upon further investigation it seems like no RTC alarm is ever received (ESP_SLEEP_WAKEUP_EXT0). What should I do?

[sqfmi]

Are all other features working and you were able to set the time?

[mipek]

Yes setting the date and time is working fine (time is just not changing), accelerometer works, BLE and WiFi seem to be working as well.

[sqfmi]

Thanks, and the battery is connected as well? The RTC clock is powered by the battery. If so, then the DS3231 RTC might be faulty. If so, send us a pic of the PCB via e-mail and we'll follow up.

[mipek]

Thank you! yes the battery is connected. I've send a mail with a picture of the pcb.

[PyroDevil]

I have the same problem. When I compile with watchy 1.2.5 I get this error:

WARNING: library DS3232RTC claims to run on avr architecture(s) and may be incompatible with your current board which runs on esp32 architecture(s).

Could that be the issue?

[Filipp1992]

Same problem here.

[c-swa]

Currently having the same issue - when uploading the example code, all of the buttons work, the WiFi, Accelerometer, and Menus work. After setting the time, it will show on the watch face, but no update the time.

I've tested rolling back the DS3232 RTC library to 1.2.12 to check and see if an earlier version would work, but the issue is still apparent.

[sqfmi]

Could you try running the rtcTimeTemp.ino example? We're trying to figure out if it's a firmware or faulty RTC

It should show something like this:

00:02:30 01Jan2000 30.50C 86.90F 00:02:40 01Jan2000 30.50C 86.90F 00:02:50 01Jan2000 30.25C 86.45F 00:03:00 01Jan2000 30.50C 86.90F 00:03:10 01Jan2000 30.25C 86.45F 00:03:20 01Jan2000 30.25C 86.45F

[Cruelshoes360]

Having the same issue. Battery, screen, buttons, WiFi, BLE, accelerometer all work. Just the time does not update and the home screen does not automatically refresh. If I shake the watch, wait over a minute to verify it is not automatically updating, go to the menu and back to the home screen the pedometer increments. Like others RTC clock seems to be the issue.

[riney]

Hello! Not to butt in but I'm having the same issue. Running rtcTimeTemp gives me the following output:

14:43:18 12Jun2021 47.50C 117.50F
14:43:20 12Jun2021 47.50C 117.50F
14:43:21 12Jun2021 49.25C 120.65F
14:43:22 12Jun2021 49.25C 120.65F
14:43:23 12Jun2021 49.25C 120.65F
14:43:24 12Jun2021 49.25C 120.65F
14:43:25 12Jun2021 49.25C 120.65F
14:43:27 12Jun2021 49.25C 120.65F
14:43:28 12Jun2021 49.25C 120.65F
14:43:29 12Jun2021 49.25C 120.65F
14:43:30 12Jun2021 49.25C 120.65F
14:43:31 12Jun2021 51.00C 123.80F
14:43:32 12Jun2021 51.00C 123.80F
14:43:34 12Jun2021 51.00C 123.80F

A couple notes:

• rtcTimeTemp delays 10 seconds between loops, but the time is incrementing about a second per iteration
• The initial time of "14:43" is what I set Watchy to, the last time I had the standard firmware on it.
• That temperature seems a bit off, too.

I tried rolling DS3232RTC back a few versions (to 1.2.7), but no difference.

Glad to try any other tests!

--John Riney

[sqfmi]

Thanks @riney this was really helpful, looks like the clock is running slow for some reason. Not sure if it's the same issue for others. Let us look into the cause for this.

[riney]

Thanks for looking into it! Let me know if there's any additional tests I can run for you. As an extra data point, if I increase the loop delay to 20s, the clock increments by 2 seconds every read. So it is legitimately running slow, not, say, incrementing every time you read it.

[alicemyslime]

I've run the same and here's my result - no increment at all. My temps are also way crazy.

15:55:10 12Jun2021 0.00C 32.00F
15:55:10 12Jun2021 0.00C 32.00F
15:55:10 12Jun2021 0.00C 32.00F
15:55:10 12Jun2021 0.00C 32.00F
15:55:10 12Jun2021 0.00C 32.00F
15:55:10 12Jun2021 0.00C 32.00F
15:55:10 12Jun2021 0.00C 32.00F
15:55:10 12Jun2021 0.00C 32.00F
15:55:10 12Jun2021 0.00C 32.00F
15:55:10 12Jun2021 0.00C 32.00F

[c-swa]

Running the rtcTimeTemp.ino provided me the same results like @aliceafterall.

I decided to give it a second shot with the TimeRTC.ino from the library, and my RTC started to provide at least proper output for time via the Serial.

23:32:59.814 -> 15:08:35 12 6 2021
23:33:00.835 -> 15:08:36 12 6 2021
23:33:01.834 -> 15:08:37 12 6 2021
23:33:02.814 -> 15:08:38 12 6 2021
23:33:03.830 -> 15:08:39 12 6 2021
23:33:04.835 -> 15:08:40 12 6 2021
23:33:05.814 -> 15:08:41 12 6 2021
23:33:06.847 -> 15:08:42 12 6 2021
23:33:07.838 -> 15:08:43 12 6 2021
23:33:08.840 -> 15:08:44 12 6 2021
23:33:09.820 -> 15:08:45 12 6 2021

[riney]

There seems to be a difference depending on whether the battery is attached. Powered only by USB, my watch face seems to update about once a minute.

[sqfmi]

@riney that is interesting as the RTC is powered by the battery. Make sure the battery is attached when testing out the time.

@c-swa the TimeRTC.ino is using a delay(1000) call, so it may not be really showing the clock running. Do you have the battery attached as well?

[PyroDevil]

For me rtcTimeTemp looks like this:

11:36:10 11Jun2021 0.00C 32.00F
11:36:10 11Jun2021 0.00C 32.00F
11:36:10 11Jun2021 0.00C 32.00F
11:36:10 11Jun2021 0.00C 32.00F

So my RTC doesn't seem to run. Battery is connected.

[mipek]

My rtcTimeTemp looks exactly like the one from PyroDevil and aliceafterall:

21:30:11 11Jun2021 0.00C 32.00F
21:30:11 11Jun2021 0.00C 32.00F
21:30:11 11Jun2021 0.00C 32.00F
21:30:11 11Jun2021 0.00C 32.00F

[Filipp1992]

For me its the same:

08:15:10 12Jun2021 0.00C 32.00F 08:15:10 12Jun2021 0.00C 32.00F 08:15:10 12Jun2021 0.00C 32.00F 08:15:10 12Jun2021 0.00C 32.00F

[asbe]

I have the same issue. Pretty sure watch face is does not get call for update at all. (I successfully connected to wifi, but icon is still crossed over. Step counter at zero) . Time/temp output on serial is stuck at same value..

Is the culprit a faulty solder? Any way to verify this in software?

Edit: step counter, weather and other icons can be updated by entering / leaving menu. Clock is still frozen.

[alicemyslime]

Regarding unplugging the battery, this indeed changes the result. Battery unplugged, test sketch uploaded, results in actual incrementing time, and a wonky temp output:

23:31:31 13Feb2009 43.50C 110.30F
23:31:32 13Feb2009 46.75C 116.15F
23:31:33 13Feb2009 46.75C 116.15F
23:31:34 13Feb2009 46.75C 116.15F
23:31:35 13Feb2009 46.75C 116.15F
23:31:36 13Feb2009 46.75C 116.15F
23:31:37 13Feb2009 46.75C 116.15F
23:31:38 13Feb2009 46.75C 116.15F
23:31:40 13Feb2009 46.75C 116.15F
23:31:41 13Feb2009 46.75C 116.15F
23:31:42 13Feb2009 48.75C 119.75F
23:31:43 13Feb2009 48.75C 119.75F

[sqfmi]

@aliceafterall interesting, so the clock seems to run OK if the battery is unplugged? Do you know if the watch face would update if it was loaded?

[sqfmi]

Also came across this https://electronics.stackexchange.com/a/445257 , sounds similar to the issue

[alicemyslime]

@aliceafterall interesting, so the clock seems to run OK if the battery is unplugged? Do you know if the watch face would update if it was loaded?

Yes, I've just confirmed this. I have the default 7-seg loaded again and it indeed wakes and updates each minute. Also, whereas initially the time was incrementing only by a second, it settled into properly updating (that is, the ten second delay resulted in 10 second increments).

Edit: I've spoken too soon - it did update initially, but is no longer updating. Re-loading the test sketch again to see if the RTC is incrementing still.

[alicemyslime]

The moment I plug the battery in:

23:35:21 13Feb2009 54.75C 130.55F
23:35:22 13Feb2009 54.75C 130.55F
> Battery plugged in here <
OSC is stopped!
23:35:23 13Feb2009 54.75C 130.55F
OSC is stopped!
23:35:23 13Feb2009 54.75C 130.55F
OSC is stopped!
23:35:23 13Feb2009 54.75C 130.55F
OSC is stopped!
23:35:23 13Feb2009 54.75C 130.55F

[PyroDevil]

With only USB connected and not battery, the RTC runs for me as well and the display gets updated. But the RTC runs very slow. For me it takes over 7 minutes for one minute on the RTC. Clock/Oscillator issues?

[electrokean]

I was just looking at the Watchy schematic and gerbers as my Watchy isn't due to arrive into Australia for another day or two. I was wondering why it was decided to power the RTC from +BATT rather than +3V3? The 3V3 regulator is always enabled, so I don't see any advantage. Using the VBAT pin on the DS3231 as a single power supply does save a little battery power, but that could still have come from the regulated 3V3.

My concern is that the RTC_INT pin is pulled up via +BATT, which could exceed 3V3 and the maximum pin specification (3.6V) with a fully charged battery. Thankfully R7 limits the current, but it isn't clear from the ESP32 docs how the GPIO pins have ESD protection diodes implemented and if this could cause problems. In any case, I don't think this is the cause of the problems reported above, just an observation.

Based on the above info from @aliceafterall and others it appears the I2C interface to the DS3231 is working with or without the battery connected, presumably with the DS3231 getting powered via leakage through the I2C pullups. Otherwise I2C errors should cause a return value of 0.

With the latest update from @aliceafterall it seems the main issue is that the oscillator stops when the power source changes on the DS3231, so the OSF and !EOSC bits in the status and control registers likely need to be monitored and cleared to restart it.

The wildly inaccurate temperature readings some people are seeing worries me, but I imagine temperature conversions stop once the oscillator stops.

Other than the above, the other possibilities are soldering problems, fake DS3231 chips, or the MEMS resonator was damaged during ultrasonic cleaning?

[alicemyslime]

With the latest update from @aliceafterall it seems the main issue is that the oscillator stops when the power source changes on the DS3231, so the OSF and !EOSC bits in the status and control registers likely need to be monitored and cleared to restart it.

I've reset these bits, both with Wire and with the library watchy uses, with no change. My code just zeros the status and control registers if it sees that the OSC stop flag was set.

[supakeen]

I was just looking at the Watchy schematic and gerbers as my Watchy isn't due to arrive into Australia for another day or two. I was wondering why it was decided to power the RTC from +BATT rather than +3V3? The 3V3 regulator is always enabled, so I don't see any advantage. Using the VBAT pin on the DS3231 as a single power supply does save a little battery power, but that could still have come from the regulated 3V3.

My concern is that the RTC_INT pin is pulled up via +BATT, which could exceed 3V3 and the maximum pin specification (3.6V) with a fully charged battery. Thankfully R7 limits the current, but it isn't clear from the ESP32 docs how the GPIO pins have ESD protection diodes implemented and if this could cause problems. In any case, I don't think this is the cause of the problems reported above, just an observation.

Based on the above info from @aliceafterall and others it appears the I2C interface to the DS3231 is working with or without the battery connected, presumably with the DS3231 getting powered via leakage through the I2C pullups. Otherwise I2C errors should cause a return value of 0.

With the latest update from @aliceafterall it seems the main issue is that the oscillator stops when the power source changes on the DS3231, so the OSF and !EOSC bits in the status and control registers likely need to be monitored and cleared to restart it.

The wildly inaccurate temperature readings some people are seeing worries me, but I imagine temperature conversions stop once the oscillator stops.

Other than the above, the other possibilities are soldering problems, fake DS3231 chips, or the MEMS resonator was damaged during ultrasonic cleaning?

I'd like to expand on this that if the chip is indeed accidentally being powered through the I2C bus then it could be that brownout detection isn't working and hence the reason for it running slowly when no battery being connected.

I do have the PCBs here but no clock module, someone could verify the truth table in the specsheet and any leakage over the bus.

[electrokean]

I'd like to expand on this that if the chip is indeed accidentally being powered through the I2C bus then it could be that brownout detection isn't working and hence the reason for it running slowly when no battery being connected.

I do have the PCBs here but no clock module, someone could verify the truth table in the specsheet and any leakage over the bus.

Actually as @sqfmi correctly pointed out, when USB is connected then the BATT/VBAT signals are powered from the TP4054 charge chip. But without any capacitors on the charge or RTC IC power pins there could be a fair bit of ripple or noise.

[khant14]

Having the same issue. Here's a couple closeup pictures of my board: https://imgur.com/a/rJ8TUsO

The RTC test script output is similar to others here:

00:00:00 01Jan2000 0.00C 32.00F 00:00:00 01Jan2000 0.00C 32.00F 00:00:00 01Jan2000 0.00C 32.00F // Battery unplugged 00:00:01 01Jan2000 50.25C 122.45F 00:00:02 01Jan2000 50.25C 122.45F 00:00:05 01Jan2000 50.25C 122.45F 00:00:06 01Jan2000 50.25C 122.45F

[sqfmi]

As a temporary workaround, update to the latest v1.2.6 of the library, and add #define ESP_RTC to Watchy.cpp

It will switch to the internal RTC and update the watch face every ~60 seconds

[alicemyslime]

For clarity, the above will allow the internal RTC to wake the watch....but the time is still read from the RTC chip, meaning the face still won't keep time without more customizations.

However the internal RTC drifts by 5%, so you'd want to implement an NTP server check-in anyway....

Edit: Actually, the code is written to increment minutes by one...it doesn't seem to be doing that, but it is there! The issue was the #define needs to be in the Watchy.cpp file, not the watchface. 😔

[PyroDevil]

@sqfmi is this a software or a hardware issue? To me it currently looks like a HW issue, and people affected should probably send those boards to you to get a working replacement, right?

How are you going to handle this?

[sqfmi]

We think this is most likely a hardware issue with a faulty RTC, we're going to setup a process so folks can send their boards in to get it repaired/replaced, will keep everyone posted.

[sthornington]

I tried the ESP RTC define but now the watch seems to run extremely fast. Going to try reverting and see what happens.

[Cruelshoes360]

I tried the ESP RTC define but now the watch seems to run extremely fast. Going to try reverting and see what happens.

I tried the ESP RTC define but now the watch seems to run extremely fast. Going to try reverting and see what happens.

The internal RTC is not very accurate... the reason for adding the additional RTC. Until the root issue is discovered (looking like bad RTC that will need to be replaced) you can look at updating the time on a schedule (maybe at the same time as temp update). Using the internal RTC is just a temporary work around.

[wkumari]

Yup, the internal RTC is far from great -- I set mine 19 hours ago, and it has lost 17 minutes so far; thats ~1 minute per hour, or 1400 seconds per day. Still, it works...

[sthornington]

Oh mine was gaining five minutes every minute. Turning it back to the onboard seems to work for me. It would definitely be nice to try to do periodic syncs with NTP servers.

[wkumari]

Yeah, mine doesn't work with the onboard one - it never increments if using the onboard one.

[JordyB16]

Same issue, received my Watchy today, got it assembled and followed all the 'get started' steps. Tried different watch faces. When uploading with Arduino i get the following error:

WARNING: library DS3232RTC claims to run on avr architecture(s) and may be incompatible with your current board which runs on esp32 architecture(s).

Bit new to Arduino so don't yet know how to get to the or run ino files All i know is time isn't changing on my watchy, i can set the time but then its stuck on that time

[Cruelshoes360]

You can ignore the warning... That is not an issue.

As a sort of work around (not very accurate) you can add a #define ESP_RTC to the Watchy.cpp file and re-upload the watch face you want to use. This will have it use the internal RTC instead of the external one that is not working.

[JordyB16]

And that's where my newbyness kicks in ;) Where can i find the watchy.ccp ? I do see the ccp files of the active watch face but how do i see the board itself? To keep this issue clean, anyone got links to some kind of tutorials?

[wkumari]

Wherever you have the Arduino stuff installed there should be a directory called libraries, and in that there should be a directory called Watchy. On my default install on my Mac it is in "Documents/Arduino/libraries/Watchy/src". In there there will be a config.h and Watchy.cpp.

[JordyB16]

Thnx, got pointed in the right direction through Discord. Got it to work with the workaround but now its losing approx 2 minutes every hour, seems to run a bit to slow. Lost 14 minutes overnight. So we'll just have to wait for a solution bij sqfmi i guess

[hn3000]

I have the RTC problem, too:

00:00:00 01Jan2000 0.00C 32.00F
00:00:00 01Jan2000 0.00C 32.00F
00:00:00 01Jan2000 0.00C 32.00F
00:00:00 01Jan2000 0.00C 32.00F
// unplug battery
00:00:05 01Jan2000 56.75C 134.15F
00:00:11 01Jan2000 57.25C 135.05F
00:00:17 01Jan2000 57.25C 135.05F
// reconnect battery
00:00:17 01Jan2000 57.25C 135.05F
00:00:17 01Jan2000 57.25C 135.05F
00:00:17 01Jan2000 57.25C 135.05F
00:00:17 01Jan2000 57.25C 135.05F
00:00:17 01Jan2000 57.25C 135.05F
// unplug battery
00:00:18 01Jan2000 57.25C 135.05F
00:00:24 01Jan2000 57.25C 135.05F
00:00:30 01Jan2000 57.25C 135.05F
00:00:36 01Jan2000 57.25C 135.05F
// reconnect battery
00:00:39 01Jan2000 57.75C 135.95F
00:00:39 01Jan2000 57.75C 135.95F
00:00:39 01Jan2000 57.75C 135.95F
00:00:39 01Jan2000 57.75C 135.95F

(Both temperatures are completely off, board is at ~36°C .)

[lhanneus]

I have a correct message every 10 seconds with the rtcTimeTemp.ino code . But none of the watchy examples actually update time correctly, it can take 24hours to increase time of 30 minutes ...

[SnoopJ]

After poking around in the ESP32 documentation[1], I discovered that there are multiple internal clocks available on the ESP32-PICO-D4. The one enabled by the above workaround is the default 150 kHz oscillator which is the lowest-power option, but has poor stability. There is also an 8 MHz oscillator which the docs say has better frequency stability. I've been using this mode for the last week or so and it definitely seems to be a better alternative, especially with temperature variation. It does require +5 μA more current in deep sleep, but the battery life is still great.

I've made the necessary changes in a fork of the library which should be usable through the Arduino IDE and tested it out with the 7_SEG example. If you're using this with custom code and want to keep track of which clock is being used, you might also want to know about the rtc_clk_slow_freq_get() and rtc_clk_slow_freq_get_hz() helpers declared in the soc/rtc.h header.

[1] config docs: https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/kconfig.html#config-esp32-rtc-clk-src, see also section 3.2 of the ESP32 technical manual: https://www.espressif.com/sites/default/files/documentation/esp32_technical_reference_manual_en.pdf for some general information about the SOC's clocks

[hsanjuan]

I've made the necessary changes in a fork of the library which should be usable through the Arduino IDE and tested it out with the 7_SEG example.

I've been testing this with an analog face (radio off). After 2 and a half days, sometimes it gests 3/4 minutes behind, now is 4 minutes ahead. Battery is at 70% or so, so seems quite ok. If we can correlate wake-up offset with temperature we might make it accurate after all.

[SnoopJ]

If we can correlate wake-up offset with temperature we might make it accurate after all.

This is one of the main things the DS3231M does. I'm not sure if people have really investigated pulling temperature data without the clock, but it's possible that maybe the software could do the same work? I'd much rather just replace the offending module for pursuing this level of accuracy.

That said, the workaround is probably not as accurate as it can be, because it's incrementing the minute counter and discarding seconds. @aliceafterall proposed on Discord that we could almost certainly do better if we used the standard library time-keeping functions instead. I haven't messed around with it yet, but if I do I'll be sure to post an update here.