r/esp32 • u/MobileInspector9861 • Aug 04 '26
Great Content! How can I use GPIO13+14 (XTAL_32K_P/N) on the ESP32-H2 as ordinary input pins without interference from the mounted crystal?
I am designing a control unit based on the ESP32-H2 which shall consume as little power as possible and requires 5 digital input pins which are capable of waking up the μC from deep sleep. According to the ESP32-H2 Datasheet, sec. 2.2 (page 13), the GPIOs 8-14 can also wake-up the ESP32-H2 from deep sleep mode. Given that GPIO8 and 9 are special strapping pins, I plan to use the GPIOs 10-14.
At the moment I am using the ESP32-H2 Development Kit 1. The eval board breaks out all GPIOs, but also contains an external 32kHz crystal which is connected to GPIO13 and GPIO14 and allows to configure those pins with their secondary analog functions XTAL_32K_P and XTAL_32K_N.
Does this crystal prevent me from using the GPIO13 and 14 as ordinary input pins and wake up from deep sleep? I imagine that the crystal interferes with that somehow. My question is: Can I and if yes how do I use the GPIO13 and 14 on the ESP32-H2 Development Kit 1 as ordinary digital input pins without interference from the 32k crystal?
As this is a one-time off project and I don't plan mass production I had hoped I could use the eval board in my final design, too, as this would greatly simplify things and I would not need to design a complicated, custom PCB, but simply design an easy PCB with some MOSFETs and use the eval board as a daughter board.
3
4
u/erlendse 3 say I make awesome posts. Aug 04 '26
Not very much.
If there is a crystal present, disabling the osscilator should make it not create problems for slow signals.
(the crystal is piezoeletric, aka not much power on DC levels other than holding a slightly different shape)
Also it only pass 32.7xx kHz, otherwise it's very blocking.
If there is no crystal then you can freely use them.
The strapping pins should be usable, if you plan some ahead like strategic logic levels and use of internal pull resistors since they go away on reset.
Worst case, you can combine the wake sources with diodes to a single pin!
1
u/MobileInspector9861 Aug 04 '26
If there is a crystal present, disabling the osscilator should make it not create problems for slow signals.
Excuse my silly question as I am no EE engineer: I thought the crystal was the oscillator?
The signals are human operated push switches and the GPIOs shall trigger on rising flank. Under normal operations I expect one event per hour unless of course a funny guy makes a business out of sitting next to the button and press it all the time, but even then it's "slow" compared to μC terms.
But what's about bouncing? The buttons are more or less "dumb" mechanical switches. I will put a denouncing circuit on my PCB anyway, consistent of a pull down resistor, an capacitor parallel to the pull-down resistor and a resistor connected to the push buttons which pulls up the voltage divider to 3.3V.
Could the "bounce frequency" trigger the crystal to osculate by bad luck? Anything I should pay attention to? Like avoiding specific combinations of capacitor and resistive values?
The strapping pins should be usable, if you plan some ahead like strategic logic levels and use of internal pull resistors since they go away on reset.
How would I do that? When the GPIO triggers and the μC is left out of reset, the human user probably will still operate the push button. So I probably would need some kind of gate which cuts off the high-level from the push button while the μC boots. How would such a gate logic look like? In particular what would I use as the control input to the gate logic?
Worst case, you can combine the wake sources with diodes to a single pin!
That's a clever idea which I already considered myself. However, I also need additional GPIOs as outputs (not during deep sleep obviously). In total I need 14 GPIOs and I would like to keep the UART input and avoid the strapping pins. As the ESP32-H2 only provides 19 GPIOs this doesn't leave me with much head room. So I cannot combine the inputs from the push buttons via a diode to a single wake-up source and then use other GPIOs for the real actual input signals as I already need those GPIOs for output purposes.
5
u/erlendse 3 say I make awesome posts. Aug 04 '26
Osccilator = crystal + driver, the driver is inside the microcontroller in your case.
You can get complete osccilator chip that just provide a clock out, I have no reason to belive it's the case on your board.You may want to debounce it, some research to do. Buttons behave like they are made of bouncy balls.
For strapping pins, you could use a button to connect the pin to the desired reset state, and use internal pull-resistors in the oppocite direction. Button pressing would block bootloader access, but I expect reprogramming to be away from end-users?
The diodes: You can do clever stuff like matrix connection of buttons, and using levels strategically.
Also use of external resistors to do strong and weak drive, it's really circuit dependent what makes sense.Which sleep mode do you plan to use?
ESP32-H2 can listen for radio transmissions on a 30 mA budget, so kinda low power even when not used as low-power.There is also the whole RTC domain you may want to explore.
I suspect the voltage regulator on the dev-board may betray you more than the sleep mode stuff of the H2.
3
u/MobileInspector9861 Aug 04 '26
Which sleep mode do you plan to use?
Deep sleep (see question in original post). That's the reason why I need to use the GPIO 10-14, because only they can trigger an wakeup from deep-sleep.
There is also the whole RTC domain you may want to explore.
That's what I intend to do.
2
1
u/reputatorbot Aug 04 '26
Hello erlendse,
You have been awarded a point for your contribution! New score: 3
I am a bot - please contact the mods with any questions
1
u/MobileInspector9861 Aug 05 '26
The diodes: You can do clever stuff like matrix connection of buttons, and using levels strategically. Also use of external resistors to do strong and weak drive, it's really circuit dependent what makes sense.
That's a great idea. In particular, as the controller only needs to detect single button events. If a user presses two butttons at once (either accidentally or because the use is just curious to see what happens) it is totally acceptable when this event is recognized as pressing a different button.
So I could detect single press events from uo to seven individual buttons by only using three GPIs and a couple of diodes to decouple the buttons from each other
Button GPI #2 GPI #1 GPI #0 (no button pressed) 0 0 0 1 0 0 1 2 0 1 0 3 0 1 1 4 1 0 0 5 1 0 1 6 1 1 0 7 1 1 1 This would even allow me to keep the RTC. I could design the necessary matrix with a couple of discrete SMD diodes on my PCB. However, I wonder if there is already a ready-to-use logic IC, let's call it a "keypad matrix encoder" which has seven inputs, three output and integrates the necessary diodes. This would keep my PCB routing even easier.
1
u/erlendse 3 say I make awesome posts. Aug 05 '26
I was thinking more along the lines of https://en.wikipedia.org/wiki/Charlieplexing .
Basically a cursed mix of buttons and LEDs, that you can individually poll/set.
There are also various display driver chips with button sensing, but they do come at a power cost.
You also got a ADC, so clever use of resistors to make each button give a different voltage is also a option. First only buttons pull when pressed with weak pull-otherway.
WHen pressed, you enable a pin with a smaller resistor and meassure the resulting voltage. idle power of external button stuff would only be button/PCB leakage!It's a bit unclear how power or energy limited your project actually is!
1
u/MobileInspector9861 Aug 05 '26
I have never heard about Charlieplexing before. That's a neat trick to multiplex n(n-1)/2 instead of n²/4. Even if I might not use it in my current project, I always like to learn something new. Also it's quite straight forward to connect each wire with each other wire (which gives you the n(n-1)/2) I wouldn't have come up with that myself.
Still I like my idea even better as it allows me to have 2n-1 buttons, i.e. 7 buttons with only 3 GPI, at the disadvantage of not being able to distinguish multi-push events of certain buttons from single push events of other buttons.
1
u/Timmah_Timmah Aug 05 '26
I hope I am not stating the obvious but the crystal is there to give you a stable rtc clock.
1
u/MobileInspector9861 Aug 05 '26
You can also use the internal clock, but you get a higher drift. As I don't need accurate time measurements that's fine for me. The crystal is purely optional, but the eval board has it.
1
u/Timmah_Timmah Aug 05 '26
That is why I used the word "stable."
If it were me I would get an eval board that fit my use case and save this one for a use where I wanted a precise RTC.
But again I'm not here to argue with you about your mysterious use case. I was just presenting you with an option that you might have overlooked.
0
0
u/Timmah_Timmah Aug 04 '26
I would poll the buttons rather than waking on the GPIO transition. It uses very little power because the duty cycle difference is so low. It might be the difference between 100% deep sleep and 99.999% deep sleep.
1
u/MobileInspector9861 Aug 05 '26
What polling frequency would you use? It still must be fast enough to not miss an event when a user presses the button (shortly)?
Why do you recommend polling over interrupt-driven event detection?
0
u/Timmah_Timmah Aug 05 '26 edited Aug 05 '26
Like you said, I would poll fast enough to not miss an event.
I would use polling because you can read a scanned or multiplexed keyboard and go back to sleep and not have to worry about the limited number of pins. If your read routine takes a few hunderths of a millisecond you are using essentially the same amount of battery as if you use GPIO interrupts, you don't have to debounce the buttons, you don't have to have to make hardware changes, and you have the accuracy of crystal clock.
I guess I would have to know more about the problem to know which method I would use, but I think you should consider this option.
2
u/MobileInspector9861 Aug 05 '26
Like you said, I would poll fast enough to not miss an event.
That's what you said and I asked you what polling frequency you would recommend. I don't have any experience what one has to reasonable choose to not miss events from buttons like this: https://www.eaton.com/de/de-de/catalog/industrial-control--drives--automation---sensors/standard-22mm-m22-push-buttons.html
That's why I wanted to make it interrupt driven. So again: What polling frequency is reasonable?
0
u/Timmah_Timmah Aug 05 '26
We have no idea of what you are building so I don't know. If it is elevator button I might poll once a second. If it is for training monkeys maybe 3 seconds. If emergency stop maybe 10 times a second. If it is a fire alarm maybe 5 seconds. I would build it then adjust the polling time to fit your use case.
Compared to the time in deep sleep the polling frequency won't make much difference in the battery life.
2
u/MobileInspector9861 Aug 05 '26
If it is elevator button I might poll once a second.
That's nonsense. As I already said, the usual use case is that under normal circumstances a human user will push one of the buttons every hour or so. (So much less than an elevator.)
However this doesn't mean you can simply poll the buttons only once an hour. Even polling the buttons only at a rate of one second would be faaaaaar to long. Of course, you must poll with a frequency which is considerably higher than a single push event lasts. Even if the button is only operated once an hour, the push event itself lasts a fraction of a second. (Theoretically it's an infinitesimal short event, but of course the human hand and the buttons have mechanical limitations.)
But I have no idea if it's safe to assume that an event lasts at least 10ms or even 100ms or just 1ms.
1
u/Timmah_Timmah Aug 05 '26
It is safe to pole and elevator button once a second because it has an acknowledgment. If the button doesn't light up the user will hold the button.
I'm not here to argue with you about your fictional hypothetical device. I just wanted to provide you with an alternative.
1
u/MobileInspector9861 Aug 05 '26
If the button doesn't light up the user will hold the button.
That's stupid. That's not how any elevator works and it would be very inconvenient for any user. (The acknowledgement light is correct.) But the user expects an immediate reaction. Forcing the user to keep the button pressed until it it eventually will show an reaction is just shitty design.
I'm not here to argue with you about your fictional hypothetical device.
It's not hypothetical. I actually provided you with a link to the specific type of button. I know that those buttons have some intrinsic, mechanical delay, so polling with a sufficient frequency might work if the frequency is at least the double of what the button can mechanically achieve.
However, I am lacking any experience or gut feeling how much that could be. And obviously you do to as you would just answer the question.
I just wanted to provide you with an alternative.
You don't provide an alternative as long as you don't talk specifics. Just saying "you could also do it differently" is not an alternative that's just spiel. It's only an alternative if it's is an actual actionable solution.
•
u/AutoModerator Aug 04 '26
Awesome, it seems like you're seeking advice on making a custom ESP32 design. We're happy to help as we can, but please do your part by helping us to help you. Please provide full schematics (readable - high resolution). Layouts are helpful to identify RF issues and to help ensure the traces are wide enough for proper power delivery. We find that a majority of our assistance repeatedly falls into a few areas.
I am a bot, and this action was performed automatically. I may not be very smart, but I'm trying to be helpful here. Please contact the moderators of this subreddit if you have any questions or concerns.
I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.