cpu/esp32: add ESP32-H2 support

[gschorcht]

Contribution description

This PR adds the support for the ESP32-H2 variant, a RISC-V based ESP32x SoC with IEEE802.15.4 and Bluetooth 5 (LE). It includes a board definition for the Espressif development board ESP32-H2-DevKitM-1.

Testing procedure

Basic tests for peripherals and ESP-specific modules have to work. Following peripherals and modules have been tested successfully:

Module	esp32h2
shell	OK
periph/adc	OK
periph/can	OK
periph/cpuid	OK
periph/dac	-
periph/flash	OK
periph/flashpage	OK
periph/gpio	OK
periph/gpio_ll	OK
periph/gpio_ll_irq	OK
periph/hwrng	OK
periph/i2c_sw	OK
periph/i2c_hw	OK
periph/pm	OK
periph/pwm	OK
periph/rtt_sys	OK
periph/rtt_hw	OK
periph/sdmmc	-
periph/spi	OK
periph/timer	OK
esp_hw_counter	-
esp_ble_nimble	OK
esp_ble_nimble + esp_wifi	-
esp_eth	-
esp_idf_gpio_hal	OK
esp_idf_usb	-
esp_idf_heap	OK
esp_ieee802154	OK
esp_now	-
esp_spi_ram	-
esp_wifi	-
esp_wifi_ap	-
esp_wifi_enterprise	-

[-] not supported by ESP32-H2

Issues/PRs references

[riot-ci]

Murdock results

:heavy_check_mark: PASSED

986cda8167e228856ec9a6a12efeefae6833d3d6 examples/gnrc/mqtt/paho-mqtt: disable WiFi for ESP32-H2

Success	Failures	Total	Runtime
10504	0	10504	23m:04s

Artifacts

• Documentation preview

[gschorcht]

@benpicco @crasbe Many thanks for your first look to this PR. I will take fix it next days.

Yes, the PR is pretty big :sunglasses: But do you really think it makes sense to split it into three PRs. Without having IEEE802.15.4 radio or BLE, the ESP32-H2 has no network interface. Unlike the other ESP32x variants, the ESP32-H2 has no WiFi interface.

For me it would not be a problem to split it as you suggested, as I have sorted the commits exactly in the order you suggested anyway, because I implemented them in that order.

[crasbe]

Not sure if it makes sense to split it now, but it would've been better if it had been split to begin with.

There are already many things to test without network interfaces on a new board and with the other two changes, the PR should be tested with other hardware too (not that I would have the required hardware though...).

[gschorcht]

Not sure if it makes sense to split it now, but it would've been better if it had been split to begin with.

@benpicco What do you think about splitting the PR. As I said, for me it would be easy to reset the PR to commit b861bb7. Locally I already have a branch cpu/esp32/add_esp32h2_ieee802154 at commit 279e292 and a branch cpu/esp32/add_esp32h2_bt at commit bd9fe35 on top of commit b861bb7.

[gschorcht]

Some additional statistics for the parts of the PR:

• commit b861bb7dfa44182be9056388c52fffc261cbefc8: ESP32-H2 base support, 64 files changed, 3291 insertions(+), 233 deletions(-)
• commit 279e292cd431d92e7549f7594440334e0b04e5d8: IEEE802.15.4 support, 25 files changed, 715 insertions(+), 12 deletions(-)
• commit bd9fe3528e50bef1458350810942573f0c2be721: ESP32-H2 BLE support, 37 files changed, 286 insertions(+), 57 deletions(-)

So the biggest part is the ESP32-H2 base support which can't be splitted further because the ESP32-H2 is another ESP32x CPU.

[benpicco]

If you want to get a proper review of the 802.15.4 support, a separate PR would be better. It's easy to lose track of this on the large PR, all the base support is rather 'boring' so it should get in quickly.

But then again we don't have anyone who properly understand the sub-MAC anymore anyway, so I can't give this part a very through review anyway, I'm just happy that it works. :smile:

[gschorcht]

Ok, I have now reset the PR to basic ESP32-H2 support. I will provide IEEE 802.15.4 and BLE support in follow-up PRs. However, without IEEE 802.15.4 and BLE support, the ESP32-H2 does not support any network interface.

[mcr]

Gunar Schorcht @.***> wrote: > without IEEE 802.15.4 and BLE support, the ESP32-H2 does not > support any network interface.

Hard to believe anything can happen without networking :-) I just watched a video about a robot control system with no network.

[gschorcht]

Hard to believe anything can happen without networking :-) I just watched a video about a robot control system with no network.

IMHO, a CPU/Board that does not have networking support isn't really supported by RIOT-OS, the Real-Time Operating system for IoT. So, if we get in the base support, we should also get in the network support in same release cycle.

[gschorcht]

I need some help or at least a recommendation. The compilation of the PR fails in the CI because I switched from the Python version of the esptool to the binary version which isn't installed in riotdocker for the moment.

The reason was that a new version of the esptool is required for the ESP32-H2 support, which in turn does not work out-of-the-box, but requires the installation of some additional Python modules. Therefore, I thought it might be easier to use the binary version of the esptool.

On the other hand, with the binary version of the esptool it isn't possible anymore to compile a project in riotdocker and to flash a pre-compiled application binary on a host that doesn't have installed the toolchain.

So I'm a bit unsure what the best approach is. There are two options:

1. Using the binary version which has the drawbacks that is not possible to flash an application binary without having the toolchain installed and that the toolchain has also to be installed in riotdocker to get it compiled in the CI.
2. Using the Python version and let the user be responsible to install required modules. Unfortunatly, there is no requirements.txt file which would make it easy.

What do you think is the best approach?

[gschorcht]

The compilation of the PR fails in the CI because I switched from the Python version of the esptool to the binary version which isn't installed in riotdocker for the moment.

Installing the Python version of esptool as a package in a virtual Python environment as part of the compilation process, as suggested in PR #21557, would solve this problem and eliminate the need to use the binary version.

[gschorcht]

After removing the esp_wifi module as netdev_default for ESP32-H2, the compilation in CI for ESP32-H2 works also without having any network interface.

[gschorcht]

@crasbe @benpicco Do you see a real chance to get the PR merged before release 2025-07? I'm not sure whether the soft freeze or the hard freeze would be the deadline for this PR because I'm not sure whether its impact is high enough for the soft freeze.

The Zephyr project already supports the EPS32-C6, but not the ESP32-H2. Both are the first ESP32 SoCs to support IEEE 802.15.4. I have RIOT-OS already working ESP32-C6 but it is implemented on top of this PR.

[gschorcht]

IMO this is good for merging.

@crasbe Thanks for reviewing and approving. So, may I squash?

[crasbe]

Yes, please squash. I was waiting if @benpicco has something else to note, but if not, you can hit merge at your own discretion.

[gschorcht]

@crasbe @benpicco Many thanks for reviewing and merging.