External RTC 32768 crystal witn ESP32-WROOM-32/ 32D D0WD
Posted: Wed Oct 25, 2023 6:52 am
Hello.
I using deep sleep and want to get more accurate RTC clocking by using external 32768 Hz crystal (GPIO32/33).
Neither BLE nor WIFI nor network stack needed. Just low power consumption during long periods (3-24 hors).
I read a lot of posts and see that there is an issue with external 32768 Hz crystal with RTC(GPIO32/33) in deep sleep mode. The issue (or issues) fixed on new chipsets ( rev >= 3.0 - D0WD-V3 and so), but rev 0, 1.0 rev 1.1 (D0WD/ D0WDQ6) ESP32 has these.
I use 5.x.x branches in my project.
Only that I can purchased now for my series device is ESP32-WROOM-32/ 32D modules (not newer ESP32E with D0WDQ6)
But I cannot find in what the issue is or any description. Only things I have found:
In official docs:
1. ESP32 Chip Revision v3.0 User Guide :
Use Case 2: Hardware Upgrade Only This is the use-case where customers have existing project which can allow hardware upgrade but software needs to remain the same across hardware revisions. In this case the project gets benefit of security to fault injection attacks, PSRAM cache bug fix and 32.768KHz crystal oscillator stability issue. The PSRAM performance continues to remain the same though.
2. Design Changes in Chip Revision v3.0 :
Optimized 32.768 KHz crystal oscillator stability. The issue was reported by client that there is a low probability that on chip revision v1.0 hardware, the 32.768 KHz crystal oscillator couldn’t start properly.
You can see here guide says about v1.0 only. What about rev 1.1?
3. Hardware design says about using additional parallel resitor with crystal for new D0WD-V3 chipset only, not for older chips (D0WD/D0WDQ6). No any limitation for D0WD
4. Errata for ESP32 has no any issue for unstable external crystal for rev 1.0 and rev 1.1 (D0WD/D0WDQ6)
What are found in forums:
1. ESP32-WROOVER should use external parallel resistor about 10MOhm. But nothing found for ESP32-WROOM32/32D
2. ULP + External crystal RTC (GPIO32/33) + deep sleep not waking up in some ESP-IDE branches 4.4(may be 4.1) or older. Nothing found about 5.0 and newer bra
3. posts say about D0WD works unstable with external crystal and deep sleep and RTC does not work in deep sleep with external crystal?!
4. Noth
Could anyone help me and explain is here any bug/issue with ESP32-WROOM-32/32D with D0WD for using external crystal 32768 with RTC (GPIO32/33)?
UPD. I found old our device with ESP32-WROOM-32 (ESP32 chip's revision 1.0 ESP32-D0WDQ6) and add the cheapest 32768Hz crystal with two 22pf. Specifically soldered them all in violation of the requirements to check work, set using external 32kHz in menuconfig.
Code initializes GPIO of ESP32 and after that goes to deep sleep (ULP disable) for 10 sec. After DEEPSLEEP_RESET as you can see everything works. Exactly 10 sec.
If I touch crystal's pins by my finger, the oscillaction fails and the WROOM switch to internal oscillator.
Also I freeezed the board with the RTC crystal to under zero temp and it also works well.
So , I cannot undestarnd is any issue or not. Today I couldnot get it.
I using deep sleep and want to get more accurate RTC clocking by using external 32768 Hz crystal (GPIO32/33).
Neither BLE nor WIFI nor network stack needed. Just low power consumption during long periods (3-24 hors).
I read a lot of posts and see that there is an issue with external 32768 Hz crystal with RTC(GPIO32/33) in deep sleep mode. The issue (or issues) fixed on new chipsets ( rev >= 3.0 - D0WD-V3 and so), but rev 0, 1.0 rev 1.1 (D0WD/ D0WDQ6) ESP32 has these.
I use 5.x.x branches in my project.
Only that I can purchased now for my series device is ESP32-WROOM-32/ 32D modules (not newer ESP32E with D0WDQ6)
But I cannot find in what the issue is or any description. Only things I have found:
In official docs:
1. ESP32 Chip Revision v3.0 User Guide :
Use Case 2: Hardware Upgrade Only This is the use-case where customers have existing project which can allow hardware upgrade but software needs to remain the same across hardware revisions. In this case the project gets benefit of security to fault injection attacks, PSRAM cache bug fix and 32.768KHz crystal oscillator stability issue. The PSRAM performance continues to remain the same though.
2. Design Changes in Chip Revision v3.0 :
Optimized 32.768 KHz crystal oscillator stability. The issue was reported by client that there is a low probability that on chip revision v1.0 hardware, the 32.768 KHz crystal oscillator couldn’t start properly.
You can see here guide says about v1.0 only. What about rev 1.1?
3. Hardware design says about using additional parallel resitor with crystal for new D0WD-V3 chipset only, not for older chips (D0WD/D0WDQ6). No any limitation for D0WD
4. Errata for ESP32 has no any issue for unstable external crystal for rev 1.0 and rev 1.1 (D0WD/D0WDQ6)
What are found in forums:
1. ESP32-WROOVER should use external parallel resistor about 10MOhm. But nothing found for ESP32-WROOM32/32D
2. ULP + External crystal RTC (GPIO32/33) + deep sleep not waking up in some ESP-IDE branches 4.4(may be 4.1) or older. Nothing found about 5.0 and newer bra
3. posts say about D0WD works unstable with external crystal and deep sleep and RTC does not work in deep sleep with external crystal?!
4. Noth
Could anyone help me and explain is here any bug/issue with ESP32-WROOM-32/32D with D0WD for using external crystal 32768 with RTC (GPIO32/33)?
UPD. I found old our device with ESP32-WROOM-32 (ESP32 chip's revision 1.0 ESP32-D0WDQ6) and add the cheapest 32768Hz crystal with two 22pf. Specifically soldered them all in violation of the requirements to check work, set using external 32kHz in menuconfig.
Code initializes GPIO of ESP32 and after that goes to deep sleep (ULP disable) for 10 sec. After DEEPSLEEP_RESET as you can see everything works. Exactly 10 sec.
If I touch crystal's pins by my finger, the oscillaction fails and the WROOM switch to internal oscillator.
Also I freeezed the board with the RTC crystal to under zero temp and it also works well.
So , I cannot undestarnd is any issue or not. Today I couldnot get it.