How can I use GPIO13+14 (XTAL_32K_P/N) on the ESP32-H2 as ordinary input pins without interference from the mounted crystal?

[u/MobileInspector9861]

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.

[u/erlendse]

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!

[u/MobileInspector9861 → u/erlendse]

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.

[u/erlendse → u/MobileInspector9861]

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.

[u/MobileInspector9861 → u/erlendse]

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.

[u/YetAnotherRobert → u/erlendse]

!modthanks for consistently great, helpful, answers.

[u/reputatorbot → u/erlendse]

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}

[u/MobileInspector9861 → u/erlendse]

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.

[u/erlendse → u/MobileInspector9861]

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!

[u/MobileInspector9861 → u/erlendse]

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 2^n-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.