Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

No RTC Wake Up #211

Open
okklar opened this issue Jul 16, 2023 · 24 comments
Open

No RTC Wake Up #211

okklar opened this issue Jul 16, 2023 · 24 comments

Comments

@okklar
Copy link

okklar commented Jul 16, 2023

No RTC wake up after deep sleep.

examples/Inkplate6COLOR/Advanced/DeepSleep/Inkplate6COLOR_RTC_Alarm_With_Deep_Sleep/Inkplate6COLOR_RTC_Alarm_With_Deep_Sleep.ino

I am trying to use this example but with no success.
Board goes to deepsleep but never wakes up. Used battery for RTC, RTC works in other context.
Are there any known issues?

Any help would be great.
Thank you!

@rsoric
Copy link
Contributor

rsoric commented Jul 19, 2023

Hi @okklar

Thanks for reporting it, dropping by to let you know we're investigating this and will let you know ASAP what the cause might be.

@rsoric
Copy link
Contributor

rsoric commented Jul 19, 2023

@okklar , So I just ran the example, and I'm getting an interrupt and the screen refreshes, in the example, there don't seem to be any other sources of wakeup so I imagine it's GPIO_NUM_39 (RTC interrupt) causing the wakeup.

I ran the Inkplate6COLOR_RTC_Alarm_With_Deep_Sleep example on the latest version of the Inkplate library main branch. The board definition for Inkplate 6COLOR shouldn't have changed in time, so the one you have is fine.

Could you please check if you have the latest version of the library?
Could you check if your Inkplate 6COLOR uses the PCAL or by any chance MCP GPIO expander? You can see this on the back of the device - the gpio expander pins are next to the device's logo printed on the PCB and they should be labeled with the name of the expander.

@okklar
Copy link
Author

okklar commented Jul 19, 2023

Hi @rsoric
thank you so much for you help and investigating that issue for me.
Unfortunately I had the same result as before, after I tried your suggestions.
The Inkplate Library is on version 8.0.0, I didn't find a later one.
Also I copied the code from github, just to double check I didn't change the local copy of the example code by accident.
No success so far.

I am not sure if I found the right GPIO Expander but if I am not mistaken it says NXP L16A 0303 ZSD201A. I will attach an picture of it.
I also see the GPIO 39 pinout on the side with the GPIO pins that are labeled with Esp32.

Once again, thanks for your help!

image

@rsoric
Copy link
Contributor

rsoric commented Jul 20, 2023

I see, that would be the PCAL GPIO expander, I just wanted to rule out the possibility that this was causing the error.

Having a look at the schematic, could you somehow check the connection on Jumper 5 - if it's fully connected to GPIO39?

Here's how it looks in the schematic:

image

As you can see, it's what connects the RTC's interrupt to the ESP32. This could be a potential cause of the error.

Here's where it is on the board:

image

The middle pad should be connected to the left pad.

@okklar
Copy link
Author

okklar commented Jul 20, 2023

Hi @rsoric .
Thank you very much for your help!

No, it is not connected, sorry, my bad – I wasn't aware of that.
So I can simply connect those two pads by soldering them?
Just to double check, it these two pads, right?

254801543-698bc787-46a8-4538-9d19-87f19ae44d46

@rsoric
Copy link
Contributor

rsoric commented Jul 20, 2023

@okklar Yes, those are the ones that should be connected - they ought to be connected by default on the PCB but it doesn't hurt to reinforce this connection so we can rule it out as a possible fault.

@okklar
Copy link
Author

okklar commented Jul 20, 2023

Hi @rsoric ,
I connected the pad this evening and I also can confirm now that they were already connected as you said.
But nothing changed unfortunately.
The code is the same, but the board still doesn't wake up after the 60 seconds.
Do you have any further things that I could check.

Sorry for that stress.

Thank you

@rsoric
Copy link
Contributor

rsoric commented Jul 21, 2023

@okklar please don't worry, we're always happy to help Inkplate users get things working :)

I'm gonna try a couple more things later today to figure out what could be causing this issue.

@rsoric
Copy link
Contributor

rsoric commented Aug 4, 2023

@okklar Sorry for the delayed reply, could you please open a support ticket with the same info you've provided here via our contact form: so we can help solve your issue

@rsoric
Copy link
Contributor

rsoric commented Dec 6, 2023

@okklar, could you please give this branch a try on your device: https://github.com/SolderedElectronics/Inkplate-Arduino-library/tree/ip6ColorSleepFix

This has an updated driver for Inkplate 6COLOR which could fix this issue, we're currently testing it. If you're going to test it with your code, note that you have to call

display.sleepColorPanel();

just before

esp_deep_sleep_start();

@rcassani
Copy link

rcassani commented Dec 17, 2023

Hi @rsoric, I'm was having the same trouble with the the Inkplate6COLOR_RTC_Alarm_With_Deep_Sleep example on the Inkplate6COLOR. I did these two things and now it is working

  • HW: Checked the connection between the GPIO39 (pin 5 in ESP32-WROVER-E) and the INT (pin 4 PCF85063A)
  • SW: Used the library from this the ip6ColorSleepFix branch (17-dec-2023)

PS. My board is different from the ones in the pictures above. I got it in the CrowdSupply campaign.
image

EDIT: It is working properly.

@rcassani
Copy link

@rsoric, After some tests, I figured out (may it is obvious) that it necessary to upload another program (let's call it reset_rtc) to reset the RTC before uploading the Inkplate6COLOR_RTC_Alarm_With_Deep_Sleep example code to make it work properly (setting the RTC). This is to say:

  1. Upload the reset_rtc code
  2. Upload the Inkplate6COLOR_RTC_Alarm_With_Deep_Sleep example
  3. It works as expected (update every 60 seconds) ✅

This is the code I'm using for reset_rtc:

#ifndef ARDUINO_INKPLATECOLOR
#error "Wrong board selection for this example, please select Soldered Inkplate 6COLOR in the boards menu."
#endif

#include "Inkplate.h"      // Include Inkplate library to the sketch
#include "driver/rtc_io.h" // Include ESP32 library for RTC pin I/O (needed for rtc_gpio_isolate() function)
#include <rom/rtc.h>       // Include ESP32 library for RTC (needed for rtc_get_reset_reason() function)

Inkplate display; // Create an object on Inkplate library

void setup() {
  // put your setup code here, to run once:
  display.begin(); // Init Inkplate library (you should call this function ONLY ONCE)
  display.rtcReset();
  display.setCursor(50, 250);
  display.setTextSize(3);
  display.setTextColor(INKPLATE_BLACK, INKPLATE_WHITE); // Set text color and background
  display.print("RTC has been reset");
  display.display();
}

void loop() {
  // put your main code here, to run repeatedly:

}

However, there is a problem that I cannot figure out, the interruption does not work if I change the date in the RTC. For example following these steps:

  1. Upload the reset_rtc code
  2. Modify the year in the line display.rtcSetDate(1, 5, 12, 2022); to be 2023.
  3. Upload the modified Inkplate6COLOR_RTC_Alarm_With_Deep_Sleep
  4. It does not update anymore ❌

Am I missing something?

@rcassani
Copy link

Reply to my own question:

Yes, I was missing this: Beside changing the year, it is necessary to also change the day, as it was different. 5-dec-2023 was Tuesday (week of the day = 2). Thus, the proper date setting is display.rtcSetDate(2, 5, 12, 2022);

@rsoric
Copy link
Contributor

rsoric commented Jan 9, 2024

Hi @rcassani ,

sorry about the delayed reply, a lot of us were on holiday for a while. Thanks for letting us know about this, we're going to make sure it's clear in a later update

-Rob

@rcassani
Copy link

Hi @rsoric, from my side everything is working fine. Tested with the latest release 10.0.0
If the RTC wake is working as well for @okklar, this issue could be closed

@okklar
Copy link
Author

okklar commented Aug 27, 2024

Hi @rsoric sorry for that very very late reply – this is literally the first day, I could test the code with the new board.

So I tested the board with the code that you flashed onto it, before sending to me – it worked fine. It woke up after 60 seconds.
Then I uploaded another inkplate example code for display test. After that I came back to the RTC Wake Up Code again and ran into the same issue I had last year. It didn't wake up anymore. But I know it worked, when I powered up the board with your code. So I found a thing.

If I set the time with "rtcSetTime()" and "rtcSetDate()" it sets up and displays the time and date correctly, but it doesn't enable the wake up alarm. If i use the "rtcSetEpoch()" to set up the time and date, the alarm is enabled correctly and it works fine again.

At the moment I have no clue, what could be the reason for that, but that is what I investigated so far.
But maybe for someone who is smater than me, that already makes perfect sense.
–T

@rsoric
Copy link
Contributor

rsoric commented Aug 27, 2024

@BornaBiro, could you have a look at this, "rtcSetTime()" and "rtcSetDate()" apparently don'tt set up the alarm correctly but "rtcSetEpoch()" does.

@BornaBiro
Copy link
Member

@okklar I don't see how one would enable or disable the RTC alarm. By looking at the rtcSetTime(), rtcSetDate and rtcSetEpoch it just sends data directly to the RTC IC. Only difference is that rtcSetEpoch() sends all time and data at one, while rtcSetTime() and rtcSetDate() splits them.

There is note in the datasheet page 22. stating that it good to read/write all time and date in one go due possible corruption. But they also said that all R/W must be done within one seconds which does happen, so this should not be a issue, especially since you can read the RTC T&D correctly. We can make a method for writing time and date at once and see the behavior.

Is this our example or your own code? Did you try to reset RTC between testing with rtcSetEpoch() and rtcSetTime()/rtcSetDate()?

@mfasold
Copy link

mfasold commented Oct 24, 2024

I am running into the same issue - the example does not work for me. I note that rtcSetAlarm works fine. Also, the epoch advances in time correctly, if I monitor it with rtcGetEpoch. Like in the example, I set the time using rtcSetTime and rtcSetDate (as I want to use the corresponding times/date as provided). I noted that the resulting epoch is many years in the future. But that is tolerable, since I just want to use rtcSetAlarmEpoch based on relative changes.

I bought the Inkplate6Color complete with everything and added the RTC battery. Any ideas?

@rsoric
Copy link
Contributor

rsoric commented Oct 25, 2024

Hi @mfasold , we're going to take some time to investigate your specific RTC issue and the others listed here in the near future, when our schedule clears a bit. Will report back here when we have some new information

-Rob

@rsoric
Copy link
Contributor

rsoric commented Nov 6, 2024

Hi @mfasold,

just tested a couple things. First I wanted to test RTC_Alarm (so, without deep sleep) which worked with a time difference of ~2 mins. Then i tried the RTC deep sleep example and I ran into some issues. First of all, the year wasn't displaying right when I was printing it back, which was concerning. I then tried to create a version of this sketch which works.

Here's the sketch I used.

And this is the output:

RTC data: 
rtc_seconds: 0 
rtc_minutes: 5 
rtc_hour: 12 
rtc_day: 6 
rtc_weekday: 4 
rtc_month: 11 
rtc_year: 24 
epoch: 3245659500 
RTC set alarm data: 
rtc_alarm_seconds: 14 
rtc_alarm_minutes: 37 
rtc_alarm_hour: 5 
rtc_alarm_day: 1 
rtc_alarm_weekday: 4

The data written to the RTC is correct, we can read it back. But the epoch received is not correct and thus also the alarm time is incorrect (because it's being set via the epoch). So, at the moment, unsure why this happens, I'm investigating this next.

So then I tried to set the alarm time via other function, and this worked.
The epoch printed is still incorrect, but if I set the alarm manually via seconds, hours etc. it seems to work. I'll have to investigate the two epoch functions.

-Rob

@mfasold
Copy link

mfasold commented Nov 6, 2024

Thank you for the investigation. That is more or less the conclusion I also arrived at. But setting the alarm in such away quickly becomes difficult, for example when using day + 1 on day 30.

@rsoric
Copy link
Contributor

rsoric commented Nov 6, 2024

Aboslutely, I'll try to somehow publish a quick fix for this now that we know the cause, hopefully during this or next week. Will keep you posted once you can download from the dev branch and try again.

@mfasold
Copy link

mfasold commented Nov 7, 2024

Thank you.

Also, I have a small suggestion. My aim is to set the RTC alarm to run at certain times each day. The interface of the function is
void rtcSetAlarm(uint8_t rtcAlarmSecond, uint8_t rtcAlarmMinute, uint8_t rtcAlarmHour, uint8_t rtcAlarmDay, uint8_t rtcAlarmWeekday). So besides the time, there is the day of the month and day of the week, but neither month nor year. The next day of the month is not easy to calculate. Therefore, it would be very convenient to have an interface without day of month, maybe even without day of week.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

5 participants