ESP32 development overview

[sylvioalves]

ESP32 Development Status

PERIPHERAL	ESP32	ESP32-S2	ESP32-C3	ESP32-S3	ESP32-C6	ESP32-C2
CPU	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:
IRQ	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:
TIMERS	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:	:heavy_plus_sign:
UART	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:
I2C	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:	:x:	:x:
SPI FLASH	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:	:x:	:x:
SPI FLASH (Octal)	N/A	N/A	N/A	:heavy_check_mark:	N/A	N/A
SPI RAM	:heavy_check_mark:	:heavy_check_mark:	N/A	:heavy_check_mark:	N/A	:heavy_check_mark:
SPI RAM (Octal)	N/A	N/A	N/A	:heavy_check_mark:	N/A	N/A
SPI	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:	:heavy_plus_sign:
Cryptography	:x:	:x:	:x:	:x:	:x:	:x:
Wi-Fi	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:	:x:	:x:
BLUETOOTH	:heavy_check_mark:	N/A	:heavy_check_mark:	:heavy_check_mark:	:x:	:x:
IEEE802.15.4	N/A	N/A	N/A	N/A	:x:	N/A
BT Mesh	:x:	:x:	:x:	:x:	:x:	:x:
GPIO	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:
TWAI	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:	:x:	:x:
E-FUSE	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:	:heavy_plus_sign:	:heavy_plus_sign:
ADC	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:	:heavy_plus_sign:	:heavy_plus_sign:
ADC DMA	:heavy_plus_sign:	:heavy_plus_sign:	:heavy_plus_sign:	:heavy_plus_sign:	:heavy_plus_sign:	:heavy_plus_sign:
DAC	:heavy_check_mark:	:heavy_check_mark:	N/A	N/A	N/A	N/A
DAC DMA	:x:	:x:	N/A	N/A	N/A	N/A
MCPWM	:heavy_check_mark:	N/A	N/A	:heavy_check_mark:	:x:	N/A
LEDPWM	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:	:heavy_plus_sign:
PCNT	:heavy_check_mark:	:heavy_check_mark:	N/A	:heavy_check_mark:	:x:	N/A
TRNG	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:	:x:	:x:
LCD	:x:	:x:	:x:	:x:	:x:	:x:
DMA SPI	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:	:heavy_plus_sign:
WATCHDOG	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:	:heavy_plus_sign:
LOW POWER Light sleep/Deep sleep	:heavy_plus_sign:	:heavy_plus_sign:	:heavy_plus_sign:	:heavy_plus_sign:	:heavy_plus_sign:	:heavy_plus_sign:
RTC	:x:	:x:	:x:	:x:	:x:	:x:
USB OTG	N/A	:x:	N/A	:x:	:x:	:x:
USB CDC	N/A	N/A	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:	:heavy_plus_sign:
ETH MAC	:heavy_check_mark:	N/A	N/A	N/A	N/A	N/A
SDHC	:heavy_check_mark:	N/A	N/A	:heavy_check_mark:	:x:	N/A
SDIO slave	:x:	:x:	:x:	:x:	:x:	:x:
I2S	:x:	:x:	:heavy_plus_sign:	:heavy_plus_sign:	:x:	:x:
ULP	N/A	:x:	N/A	:x:	:x:	:x:
SMP	:x:	N/A	N/A	:x:	N/A	N/A
AMP	:heavy_plus_sign:	N/A	N/A	:heavy_plus_sign:	N/A	N/A
FLASH ENCRYPTION	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:	:heavy_plus_sign:
DFS	:x:	:x:	:x:	:x:	:x:	:x:
OPENOCD	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:	:heavy_plus_sign:
MCUBOOT (Zephyr port, basic cyber security)	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:	:heavy_plus_sign:
MCUBOOT (Espressif port, secure boot V2)	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:	:heavy_plus_sign:

Last update: 30/Aug/2024

• :heavy_check_mark: Feature is supported.
• :heavy_plus_sign: Work in progress.
• :x: Feature is not supported
• N/A: Not applicable to this device.

Introduction

This RFC gives an overview of features and enhancements we plan to contribute for Espressif's ESP32 SoC device. It is not intended to be a proper roadmap but it gives some information about our effort on having more support for Zephyr RTOS.

Problem description

Currently, ESP32 support consists of a few peripheral implementations as such as GPIO, UART and I2C, which limits device usage on Zephyr. There are missing peripheral drivers as such as WiFi and BLE that are very often requested by the community, but lack implementation.

Proposed change

The proposal is to enable the powerful features that ESP32 SoC can offer, starting by bringing up WiFi subsystem. Meanwhile, we shall also work on developing yet unsupported peripheral drivers.

Detailed RFC

Initial Development

As there have already been some work on the WiFi bring up, a few modifications can be listed below describing initial requirements:

• Add ESP-IDF bootloader that handles SoC initialization (cache, MMU and partition tables). In long term, Zephyr's bootloader might be supported as well.
• Set XIP support by default to support ESP-IDF bootloader.
• Update linker script with proper flash, ram sections and symbols map.
• Update clock settings and entropy drivers.
• Add timer/counter support.
• Add NVS support.
• Add Wifi sources and network drivers.

WiFi Driver and Network Integration

We have already implemented the WiFi adapter driver, which binds ESP32 internal WiFi to Zephyr's ETHERNET_L2 layer. However, Zephyr has yet no support for WiFI SoC that runs as non-offloaded driver. It means that creating a network device following subsys/net/l2/wifi/wifi_mgmt.c API does not allow binding to the ETHERNET_L2. There is no such implementation for a WIFI_L2 layer, which would allow using WIFI_MGMT API to integrate with ETHERNET_L2 layer.

This will be addressed in another issue focused on network integration and user API.

ESP32 HAL Module

To keep the folder structure in sync with other vendors, and to update ESP-IDF source to version 4.2, repository modules/hal/esp-idf shall be updated to modules/hal/espressif. Only minimal and necessary ESP-IDF sources shall be included in this repository, which includes source files, adapter layers and symbols to handle internal calls. It will require changing west.yml to point to this new branch.

Peripherals

The list below shows currently unsupported peripherals. We plan to start developing a few drivers in long term. Porting all the components is tricky due to FreeRTOS dependency in the current ESP-IDF implementation. SPI related code has special considerations due to dual-core SoC architecture and XIP (code execution from Flash). BLE and WiFi share the same RF radio, which implies handling their coexistence by hardware or software. ESP-IDF already takes care of everything but the porting is not straightforward. Also, we still have to analyze issues regarding multi-core support, SMP and power management.

• SMP
• DMA
• ULP
• ADC
• DAC
• CAN
• I2S

Future Plans

Future Devices

It is well known that Espressif has other chipsets on its platforms. We plan to add support to them as well when a reasonable ESP32 support on Zephyr is achieved for product level usage. For the time being, there are plans to add support for (not in any chronological order):

• ESP32-H2 (TBD)
• ESP32-H4 (TBD)
• ESP32-P4 (TBD)

More may be added to the list as Espressif adds more chipsets to its linecard.

[ExtremeGTX]

I think after ESP32 WiFi Support a lot of basic stuff will be fixed, like WIFI, Flash Cache, 2nd Stage Bootloader support, Linker script updates.

Could you please tell us if there are any progress on the mentioned drivers ? (for cooperation and avoiding double efforts)

[sylvioalves]

The items below are implemented. We are a few days of creating a PR for that:

Add ESP-IDF bootloader that handles SoC initialization (cache, MMU and partition tables). In long term, Zephyr's bootloader might be supported as well.
Set XIP support by default to support ESP-IDF bootloader.
Update linker script with proper flash, ram sections and symbols map.
Update clock settings and entropy drivers.
Add timer/counter support.
Add NVS support.
Add Wifi sources and network drivers.

We also expect to start working on SPI for the next days.

[chrta]

Could you add some information when/if Secure Boot and Flash Encryption are planned?

[sylvioalves]

Could you add some information when/if Secure Boot and Flash Encryption are planned?

Sure. I can't tell you exactly when but It is on our development backlog. I'll update you once we get ourselves working on it.

[mrrosen]

Note, I added support for ESP32-S2 in a PR a while back but since it required an unreleased version of the ESP-IDF (v4.2), I stalled work on that PR until Espressif officially released a stable version supporting ESP32-S2; If youre changing the way Zephyr includes the IDF, Id be happy to adapt my PR for it but I think waiting on a stable release of it would be best (https://github.com/zephyrproject-rtos/zephyr/pull/27246)

[mahavirj]

@mrrosen

I added support for ESP32-S2 in a PR a while back

Thank you for update.

If youre changing the way Zephyr includes the IDF, Id be happy to adapt my PR for it but I think waiting on a stable release of it would be best

Yes we are trying to align with stable ESP-IDF v4.2 release timelines. Release candidate is due sometimes next week, followed up by formal announcement. Regarding how Zephyr consumes IDF, some discussions are on-going at https://github.com/zephyrproject-rtos/esp-idf/issues/4, we will keep you posted on your PR for ESP32-S2 support based on our progress.

[mrrosen]

@sylvioalves Since ESP-IDF v4.2 has been finally been released, what is the plan for updating the esp-idf/hal_espressif so I can align my ESP32-S2 PR to it?

[sylvioalves]

@mrrosen, we are waiting approval to use this hal_espressifbranch: https://github.com/sylvioalves/hal_espressif/tree/zephyr
It is based on release/v4.2 and will probably make easier for you to rebase. I'll update you once we get on track.

[shlomow]

Hi! I saw some forks that contain some features for the esp32. Maybe it will be useful if anyone that works on features for the esp32 can post here his fork. It will remove any duplication of work and allow people to test and use some code which has not upstreamed yet. I intend to add support for spi and I hope that I am not duplicating this.

[sylvioalves]

Yes, we need to handle that in some way. Regarding SPI, we have already implemented SPI2 and SPI3 drivers but it is under internal review. Same for timer drivers. Once we have a few PRs merged, we will push it as well.

[DRNadler]

Great to hear of your progress on ESP32! In case you do not have enough to do, if I understand correctly S3 adds USB - perhaps USB support should go on the list? Thanks for your efforts!

[oldrev]

Thanks for your great effort.

Is there any chance to support the SmartConfig mechanism?

[K2AAE]

It's been awhile, any updates? Just purchased a ESP32-S2

[tiborrr]

@sylvioalves how is the progress going on security features like secure boot and flash encryption?

[sylvioalves]

@sylvioalves how is the progress going on security features like secure boot and flash encryption?

Hi @tiborrr, our current efforts are directed to support ESP32S2 and ESP32C3. For security, so far, we haven't advanced on such front. But I invite you to attend to our lightning talk about our plans on Zephyr Summit.

[tiborrr]

@sylvioalves how is the progress going on security features like secure boot and flash encryption?

Hi @tiborrr, our current efforts are directed to support ESP32S2 and ESP32C3. For security, so far, we haven't advanced on such front. But I invite you to attend to our lightning talk about our plans on Zephyr Summit.

I already have registered so I will definitely join the talk. Thanks for the update!

[torntrousers]

@sylvioalves how is the progress going on security features like secure boot and flash encryption?

Hi @tiborrr, our current efforts are directed to support ESP32S2 and ESP32C3. For security, so far, we haven't advanced on such front. But I invite you to attend to our lightning talk about our plans on Zephyr Summit.

Is there a recording of that talk available somewhere?

[tiborrr]

@torntrousers The recording is not yet online however the slides are. Perhaps you can find what you need in there.

https://drive.google.com/file/d/1AmP1R9Mr08nqR_wwNLsgOHaiKaLR9UlS/view?usp=sharing

[torntrousers]

@torntrousers The recording is not yet online however the slides are. Perhaps you can find what you need in there.

https://drive.google.com/file/d/1AmP1R9Mr08nqR_wwNLsgOHaiKaLR9UlS/view?usp=sharing

Thanks!

I'm completly new to Zephyr and this morning have been trying to get it running on an ESP32 but really quite lost - none of the doc or guides I can find seem to work right away or be quite up to date. Is there something up to date somewhere that would tell me how to get helloworld or blinky running on an ESP32 (using a Windows environment, sorry)?

[tiborrr]

@torntrousers i actually switched to Ubuntu because of your experience. Getting USB to work on WSL was a pain. Now that I've switched to Ubuntu developing has been a treat.

[sylvioalves]

@torntrousers Hi, after having your environment properly set, follow the guide below:
https://docs.zephyrproject.org/latest/boards/xtensa/esp32/doc/index.html

Let us know if you still face any issue.

[torntrousers]

Thanks @sylvioalves , I have things compiling but can't get the standard samples working, eg: https://github.com/zephyrproject-rtos/zephyr/issues/36412 and https://github.com/zephyrproject-rtos/zephyr/issues/36414

[protobits]

WiFi Driver and Network Integration

We have already implemented the WiFi adapter driver, which binds ESP32 internal WiFi to Zephyr's ETHERNET_L2 layer. However, Zephyr has yet no support for WiFI SoC that runs as non-offloaded driver. It means that creating a network device following subsys/net/l2/wifi/wifi_mgmt.c API does not allow binding to the ETHERNET_L2. There is no such implementation for a WIFI_L2 layer, which would allow using WIFI_MGMT API to integrate with ETHERNET_L2 layer.

This will be addressed in another issue focused on network integration and user API.

Hi, any progress on this? I ask since I registereded callbacks for CARRIER_UP/DOWN events to get notified when WiFi is connected/disconnected but it is problematic since sometimes the connection attempt fails and the CARRIER_DOWN event is not generated, since it was never up in the first place (I do get the DOWN event after an UP event). I need to handle these events myself because reconnection on connection loss (via CONFIG_ESP32_WIFI_STA_RECONNECT) is not aware of a manual disconnection and attempts to reconnect again. Also, I need the events to only start tasks (such as connecting to MQTT broker) when a connection is up (otherwise I need to brute force connect attempts).

[sylvioalves]

@protobits Working on it.

[jli157]

@sylvioalves do you have plan to support the USB Device Mode on ESP32-S2(S3)? Thank you!

[sylvioalves]

@sylvioalves do you have plan to support the USB Device Mode on ESP32-S2(S3)? Thank you!

@jli157 Hi, thanks for asking. We have not planned that yet since we have just started ESP32S2 and ESP32C3 support. We have a long way before getting into USB device mode support, which includes low power mode, basic peripherals and so. Recently we shared our plans during Zephyr's summit. Find the link below in case you missed it.
https://youtu.be/Lct81v9CYzg

I'll bring more information in this channel once we update the development status.

[johnnyguoyy]

Looking forward to the DMA driver!

[wimmatthijs]

Could we update the overview? looking to start a new project, but not completely clear what is supported in the current version and what not.... Thanks

[filipeaguiar22]

Hi, I have an ESP32 board with a 26 MHz clock, so in need to configure the IDF ESP32_XTAL_FREQ I have been trying to figure out how to configure the clock, but the configurations are not in west build -t guiconfig -b esp32 Thanks

[glaubermaroto]

Hi, I have an ESP32 board with a 26 MHz clock, so in need to configure the IDF ESP32_XTAL_FREQ I have been trying to figure out how to configure the clock, but the configurations are not in west build -t guiconfig -b esp32 Thanks

@filipeaguiar22 It may be helpful to you knowing that the following PR was submitted: #38543

[rftafas]

FWIW, updated list: https://www.espressif.com/en/news/new_operating_systems_in_ESP32

[gera-k]

The cpp_synchronization sample doesn't work on esp32c3. It looks like constructors for static objects are not called. Found that the init_array_start/end are defined twice in the .map. Was able to workaround the problem by commenting out the corresponding part of zephyrproject/zephyr/include/linker/common-rom.ld: /* SECTION_PROLOGUE(init_array,,) { . = ALIGN(4); __init_array_start = .; KEEP(*(SORT_BY_NAME(".init_array*"))) __init_array_end = .; } GROUP_ROM_LINK_IN(RAMABLE_REGION, ROMABLE_REGION) */ Not sure what is the 'right' way of fixing it.

[sylvioalves]

@gera-k, thanks, will take a look.

[gera-k]

a question when i do uint64_t = uint32_t * uint32_t in C, the gcc generates mul mulh while RISC-V instruction manual suggests the opposite order of mul instructions when 64-bit result is required. Is C3 CPU smart enough to do single multiplication in this case? If not, is there a way to tell gcc to generate muls in right order?

[sylvioalves]

a question when i do uint64_t = uint32_t * uint32_t in C, the gcc generates mul mulh while RISC-V instruction manual suggests the opposite order of mul instructions when 64-bit result is required. Is C3 CPU smart enough to do single multiplication in this case? If not, is there a way to tell gcc to generate muls in right order?

@gera-k As far from a few discussion I had, it just work as is. For some reaso, when optimization is disabled, the mul order is indeed not following ISA recommendation. When opt. is enabled (any), it is in correct order. Anyway, it works. Have you faced any issue at all?

[gera-k]

It seems it gives me wrong order with -O2. Anyway, i tried forcing the correct order by inline assembly and it doesn't make noticeable difference in performance.

[MDr164]

@sylvioalves how is the progress going on security features like secure boot and flash encryption?

Hi @tiborrr, our current efforts are directed to support ESP32S2 and ESP32C3. For security, so far, we haven't advanced on such front. But I invite you to attend to our lightning talk about our plans on Zephyr Summit.

Quite a few months have passed and the support of the ESP32 in Zephyr seems to be quite ironed out. There are no Kconfigs yet, that would switch these features on itself, right? So far my path was to compile everything manually (e.g. ESP-IDF bootloader with encryption etc.) and then flash the Zephyr binary into the app partition. There is no more elegant way at the moment, or am I missing anything?

[beriberikix]

FWIW, MCUboot is also now supported and we're using it successfully. We wrote about how to get it working with our platform here but should be generally applicable.

[MDr164]

For unfortunate reasons we can't use MCUBoot on the current project I'm working on. It would have been the desired path but nothing I can use for right now, even though it would have met all requirements.

[rftafas]

@sylvioalves how is the progress going on security features like secure boot and flash encryption?

Hi @tiborrr, our current efforts are directed to support ESP32S2 and ESP32C3. For security, so far, we haven't advanced on such front. But I invite you to attend to our lightning talk about our plans on Zephyr Summit.

Quite a few months have passed and the support of the ESP32 in Zephyr seems to be quite ironed out. There are no Kconfigs yet, that would switch these features on itself, right? So far my path was to compile everything manually (e.g. ESP-IDF bootloader with encryption etc.) and then flash the Zephyr binary into the app partition. There is no more elegant way at the moment, or am I missing anything?

Hi!

As stated before by @beriberikix, we already support secure boot and other boot-related features through MCUboot. Same with Flash Encryption, it is available with MCUboot. Full IDFboot support is not on our roadmap, as they are equivalent to the more 'Zephyr standard' MCUboot features.

As @sylvioalves said, but adding that it is due to such equivalence, our efforts are now on PinCtrl, Low Power, SOC (S2/S3) support and AMP (AMP is currently part of our S3 support efforts).

That said, as for IDFboot: it's possible to use it with some tinkering, though, for those with an imperative need for both IDFboot and Zephyr. We haven't prevented that in any form. Further for my understanding: the only scenario that I can imagine for such situation (mandatory IDFboot) is a product that was shipped with ESP-IDF image and must move to Zephyr. I would be glad if you could share your scenario.

[MDr164]

You nailed the scenario there. The product used FreeRTOS with IDF in a previous iteration and switches now over to Zephyr. The update happens as part of an OTA update so replacing the bootloader in the field that way is out of scope. I wish we had more flexibility there. Otherwise thanks for the feedback and looking forward to the S3 work!

[maximevince]

Is there visibility on the Low Power support for ESP32 on Zephyr? (and especially interested in the C3) Is this started / planned / available for testing / ... ?

[beriberikix]

Would it be possible to create an up to date table of the supported features like what was shared on the Espressif Blog? Thank you!

[rftafas]

Is there visibility on the Low Power support for ESP32 on Zephyr? (and especially interested in the C3) Is this started / planned / available for testing / ... ?

We completed one milestone related to this (PinControl). Now we are planning and doing the priority check against other tasks. Any specifics you would like to share? Need for deep sleep? Do you intend to control the ULP / write code for it? Since ULP is different on ESP32 and ESP32S2, any target?

[wolterhv]

Hi, I'm interested in adding support for the ESP32 ADC. I've opened #44908 for this purpose. Any willingness to collaborate is very welcome.

[sam131208]

@sylvioalves Do you have any plans to release S3 support?

[henrikbrixandersen]

I have started work on adding support for the ESP32 CAN controller.

[rftafas]

@sylvioalves Do you have any plans to release S3 support?

ICYMI: https://github.com/zephyrproject-rtos/hal_espressif/issues/97

[maximevince]

Is there visibility on the Low Power support for ESP32 on Zephyr? (and especially interested in the C3) Is this started / planned / available for testing / ... ?

We completed one milestone related to this (PinControl). Now we are planning and doing the priority check against other tasks. Any specifics you would like to share? Need for deep sleep? Do you intend to control the ULP / write code for it? Since ULP is different on ESP32 and ESP32S2, any target?

Especially getting the device into deep sleep from a Zephyr application is the first major goal to getting to a viable battery powered device (talking multiple years on a primary battery cell). Thanks for the replies here, much appreciated!!

[GuptaAshi-Eaton]

Hello,

By when we can expect support for ESP32-S3 in Zephyr ? As per timeline given on https://www.espressif.com/en/news/new_operating_systems_in_ESP32 this would have available by Q1. Is there any new timeline ? I have asked this question in other forum but no timeline has been provided. Also is there any development PR or branch that can be referred.