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

[ESP32S3] v4.4 deep_sleep sleeping more than should (IDFGH-10088) #11363

Closed
3 tasks done
KonssnoK opened this issue May 9, 2023 · 7 comments
Closed
3 tasks done

[ESP32S3] v4.4 deep_sleep sleeping more than should (IDFGH-10088) #11363

KonssnoK opened this issue May 9, 2023 · 7 comments
Assignees
Labels
Resolution: NA Issue resolution is unavailable Status: Done Issue is done internally

Comments

@KonssnoK
Copy link
Contributor

KonssnoK commented May 9, 2023

Answers checklist.

  • I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
  • I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
  • I have searched the issue tracker for a similar issue and not found a similar issue.

General issue report

issue is quite simple:

  • we put 30 minutes sleep, device sleeps 40 minutes
  • we put 1 hour sleep, device sleeps 1.5hours
  • we put 1.5 hours sleep, device sleeps 3hours

Any idea on how to improve accuracy?

In the settings

- 150000 Hz if internal RC oscillator is used as clock source. For this use value 1024. 
- 32768 Hz if the 32k crystal oscillator is used. For this use value 3000 or more. 
- In case more value will help improve the definition of the launch of the crystal. 
- If the crystal could not start, it will be switched to internal RC.

should we consider the 8MHz as a 32kHz?

our RTC settings:
image

@espressif-bot espressif-bot added the Status: Opened Issue is new label May 9, 2023
@github-actions github-actions bot changed the title [ESP32S3] v4.4 deep_sleep sleeping more than should [ESP32S3] v4.4 deep_sleep sleeping more than should (IDFGH-10088) May 9, 2023
@igrr
Copy link
Member

igrr commented May 9, 2023

Linking #9455 which seems to be related.

@KonssnoK
Copy link
Contributor Author

KonssnoK commented May 9, 2023

i forgot to put the v4.4 reference -> 3cec3a0

@10086loutianhao
Copy link
Collaborator

I will take a look at this issue

@10086loutianhao
Copy link
Collaborator

I see that the latest master branch has resolved this issue. Indeed, when using 8Md256, the improper PMU parameters caused abnormal counting in the lp_timer. The more appropriate parameters have been implemented on the latest master branch. (The cause of the malfunction is the same as in GH#11362)

@10086loutianhao
Copy link
Collaborator

If you want, you can also make direct modifications to the current code in rtc_sleep.c.
To make the requested modification in the C file on line 83,
change:
if (sleep_flags & RTC_SLEEP_USE_ADC_TESEN_MONITOR) {
to:
if ((sleep_flags & RTC_SLEEP_USE_ADC_TESEN_MONITOR) || (!(sleep_flags & RTC_SLEEP_PD_INT_8M))) {

@espressif-bot espressif-bot added Status: Selected for Development Issue is selected for development and removed Status: Opened Issue is new labels Jun 7, 2023
@KonssnoK
Copy link
Contributor Author

KonssnoK commented Nov 7, 2023

@10086loutianhao was this merged in v4.4?

@10086loutianhao
Copy link
Collaborator

@10086loutianhao was this merged in v4.4?
Yes, the solution here should be the same as the one in #11362. Please check it.

@KonssnoK KonssnoK closed this as completed Nov 7, 2023
@espressif-bot espressif-bot added Status: Done Issue is done internally Resolution: NA Issue resolution is unavailable and removed Status: Selected for Development Issue is selected for development labels Nov 9, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Resolution: NA Issue resolution is unavailable Status: Done Issue is done internally
Projects
None yet
Development

No branches or pull requests

5 participants