Zephyr on the ESP32

[cbrake]

This topic is to explore running Zephyr on ESP32 devices. To start, we have four boards:

• Olimex ESP32-POE-ISO (ESP32-WROOM-32E module, Xtensa)
• EzSBC ESP32 Breakout and dev board (ESP32-WROOM-32 module, Xtensa)
• ESP32-C-DevKitC (ESP32-C3-WROOM-02, RiscV)
• ESP32-C-DevKitM (ESP32-C3-MINI-1, RiscV)

Two boards with the ESP32-WROOM modules (Xtensa microprocessor) and two boards with the ESP32-C3 (RISC-V).

The process to build and flash Zephyr is similar for both architectures:

C3 RiscV:

west build -b esp32c3_devkitm --sysbuild samples/hello_world

Xtensa:

west build -b esp_wrover_kit --sysbuild samples/hello_world

And to flash:

west flash

You can run tio on the serial port to view the console.

ESP-ROM:esp32c3-api1-20210207
Build:Feb  7 2021
rst:0x1 (POWERON),boot:0xc (SPI_FAST_FLASH_BOOT)
SPIWP:0xee
mode:DIO, clock div:2
load:0x3fcc1e00,len:0x1fd0
load:0x403b6e00,len:0x7844
load:0x403bee00,len:0x1200
entry 0x403b92e6
I (48) boot: MCUboot 2nd stage bootloader
I (48) boot: compile time May 23 2024 18:07:00
I (48) boot: Multicore bootloader
I (49) spi_flash: detected chip: generic
I (52) spi_flash: flash io: dio
W (54) spi_flash: Detected size(4096k) larger than the size in the binary image header(2048k). Using the size in the binary image header.
I (67) boot: chip revision: v0.3
I (69) boot.esp32c3: SPI Speed      : 40MHz
I (73) boot.esp32c3: SPI Mode       : SLOW READ
I (78) boot.esp32c3: SPI Flash Size : 4MB
I (81) boot: Enabling RNG early entropy source...
I (97) spi_flash: flash io: dio
[esp32c3] [INF] Image index: 0, Swap type: none
[esp32c3] [INF] Loading image 0 - slot 0 from flash, area id: 1
[esp32c3] [INF] Application start=40380730h
[esp32c3] [INF] DRAM segment: paddr=000136f0h, vaddr=3fc836c0h, size=0053ch (  1340) load
[esp32c3] [INF] IRAM segment: paddr=00010040h, vaddr=40380000h, size=036b0h ( 14000) load
[esp32c3] [INF] DROM segment: paddr=00020000h, vaddr=3c000000h, size=005B0h (  1456) map
[esp32c3] [INF] IROM segment: paddr=00030000h, vaddr=42010000h, size=02508h (  9480) map

*** Booting Zephyr OS build v3.6.0-4560-g11920e35a00e ***
Hello World! esp32c3_devkitm/esp32c3

The development process feels very similar between the Xtensa and RiscV devices.

Next steps will be to configure the WiFi networking and the Ethernet on the Olimex board.

[khem]

@cbrake

Next steps will be to configure the WiFi networking a

I think RISV on Zephyr is match made in heaven. We will see standard OSS on standard OpenSource ISA implementing h/w

[cbrake]

Ethernet support

Zephyr includes support for the ESP32-ETHERNET-KIT:

• ESP32-ETHERNET-KIT — Zephyr Project Documentation
• ESP32-Ethernet-Kit V1.2 Getting Started Guide - ESP32 - — ESP-IDF Programming Guide latest documentation
• https://dl.espressif.com/dl/schematics/SCH_ESP32-Ethernet-Kit_A_V1.2_20200528.pdf

Schematics

ESP32-ETHERNET-KIT Ethernet circuitry

Olimex ESP32-POE-ISO Ethernet Circuitry

[cbrake]

Espressif has a nice page on the Zephyr efforts:

Update on Espressif’s Support for Zephyr | Espressif Systems

Looks like they are doing things right.

[cbrake]

Ended up getting an ESP32-ETHERNET-KIT (far right in photo below):

I built the Ethernet sample:

west build -b esp32_ethernet_kit/esp32/procpu samples/boards/esp32/ethernet/

The Ethernet cable was detected by the Phy, but the Ethernet interface did not come up:

[00:00:01.104,000] <inf> phy_mii: PHY (1) ID 2430C54

*** Booting Zephyr OS build v3.6.0-5816-gaca152a94165 ***
[00:00:01.108,000] <inf> net_config: Initializing network
[00:00:01.108,000] <inf> net_config: Waiting interface 1 (0x3ffb5f08) to be up...
[00:00:06.916,000] <inf> phy_mii: PHY (1) Link speed 100 Mb, full duplex

[00:00:31.109,000] <inf> net_config: Running dhcpv4 client...
[00:00:31.109,000] <err> net_config: Timeout while waiting network interface
[00:00:31.109,000] <err> net_config: Network initialization failed (-115)

I then tried the ESP32 Ethernet sample on an STM32 H7 board – it worked fine. After reporting the issue on the Espressif channel on Discord, a developer from Espressif suggested a solution, and now it works! Apparently, something broke in some recent clock refactoring.

[00:00:07.017,000] <inf> phy_mii: PHY (1) Link speed 100 Mb, full duplex

[00:00:07.017,000] <inf> net_config: Interface 1 (0x3ffb5f08) coming up
[00:00:07.017,000] <inf> net_config: Running dhcpv4 client...
[00:00:09.607,000] <inf> net_dhcpv4: Received: 10.0.0.135
[00:00:09.607,000] <inf> net_config: IPv4 address: 10.0.0.135
[00:00:09.607,000] <inf> net_config: Lease time: 600 seconds
[00:00:09.607,000] <inf> net_config: Subnet: 255.255.255.0
[00:00:09.607,000] <inf> net_config: Router: 10.0.0.1

The above issue also links to another discussion that may be the key to getting the Ethernet working on the Olimex board, which uses a ESP32 GPIO to generate the 50MHz Phy clock.

This illustrates several things:

1. Community is important. A developer from Espressif was aware of some recent changes that might have broke something – they had context.
2. This also illustrates the advantage of developing on the main branch – you can get good support there as that is where the MCU developers are working. If you want support on an older LTS release, you better have a support contract in place.
3. The support for using a GPIO pin for Phy clock was recently added – again, if you want to use features a little off the beaten path, developing on main is a good place to be.
4. Proving something works on a competitor’s MCU is a good motivator and a good check to make sure the core OS components are working. It is amazing how I can build the same application on ESP32 and STM32 parts.
5. Having the MCU vendor’s official development board allowed me to get quick support from the vendor as they could replicate the problem. If we had to debug this on the Olimex board, it would have been time-consuming as several things are different.
6. When dealing with a complex system, break it down and verify it one step at a time.

Now to get the Phy clock running on the Olimex ES32-POE …

[khem]

yeah more upstream you go, better the water is for drinking, its nature’s law

[cbrake]

Ethernet is now working on the Olimex ESP32-POE under Zephyr!

[00:00:00.210,000] <inf> phy_mii: PHY (0) ID 7C0F1
                                                                                                                     
[00:00:00.212,000] <inf> eth_esp32: APLL is occupied already, it is working at 50000000 Hz
*** Booting Zephyr OS build v3.7.0-rc1-375-g9f927f97847f ***
[00:00:00.225,000] <inf> net_config: Initializing network
[00:00:00.225,000] <inf> net_config: Waiting interface 1 (0x3ffb5d00) to be up...
uart:~$ SIOT Zephyr Application! esp32_poe/esp32/procpu
[00:00:03.418,000] <inf> phy_mii: PHY (0) Link speed 100 Mb, full duplex
                                                                                                                     
[00:00:03.418,000] <inf> net_config: Interface 1 (0x3ffb5d00) coming up
[00:00:03.418,000] <inf> net_config: Running dhcpv4 client...
[00:00:08.423,000] <inf> net_dhcpv4: Received: 10.0.0.148
[00:00:08.423,000] <inf> net_config: IPv4 address: 10.0.0.148
[00:00:08.423,000] <inf> net_config: Lease time: 600 seconds
[00:00:08.423,000] <inf> net_config: Subnet: 255.255.255.0
[00:00:08.423,000] <inf> net_config: Router: 10.0.0.1

Some fixes have been merged for ESP32 Ethernet and one PR is still pending. The complete build is here:

GitHub - simpleiot/zephyr-siot: Simple IoT application for Zephyr

This is a Zephyr Workspace T2 topology that pulls in Zephyr as a dependency.

Notice right now, we are referencing a PR repo/branch that has the fixes we need.

manifest:
  remotes:
    - name: zephyrproject-rtos
      url-base: https://github.com/zephyrproject-rtos
    - name: zephyr-sylvio
      url-base: https://github.com/sylvioalves
    - name: zephyr-iwasz
      url-base: https://github.com/iwasz
  projects:
    - name: zephyr
      remote: zephyr-iwasz
      revision: initialize_ref_clk_in_mdio_esp32
      import: 
        name-allowlist:
          - hal_espressif
          - hal_stm32
          - cmsis
  self:
    path: siot

This has been a community effort:

ESP32 MDIO not working correctly when RMII clock is generated on GPIO17 ·...

[cbrake]

Zephyr NVS (non-voltatile storage) storage works out-of-the box on ESP32 CPUs:

add NVS config for ESP32 boards

initialize NVS memory and store boot count

Currently storing boot count, but can eventually be used to store other config settings.

[00:00:03.322,000] <inf> net_config: Interface 1 (0x3ffb6610) coming up
[00:00:03.322,000] <inf> net_config: Running dhcpv4 client...
[00:00:03.322,000] <inf> siot: SIOT Zephyr Application! esp32_poe/esp32/procpu
[00:00:03.322,000] <dbg> fs_nvs: nvs_recover_last_ate: Recovering last ate from sector 0
[00:00:03.331,000] <inf> fs_nvs: 3 Sectors of 4096 bytes
[00:00:03.331,000] <inf> fs_nvs: alloc wra: 0, fc0
[00:00:03.331,000] <inf> fs_nvs: data wra: 0, 14
[00:00:03.331,000] <inf> siot: Id: 1, boot_counter: 4

The boot_counter is preserved even when you flash new firmware.

[cbrake]

ESP32 Pinmux

The ESP32 Pinmux is pretty flexible – many of the peripherals can be mapped to any GPIO pin:

In the include/zephyr/dt-bindings/pinctrl/esp32-pinctrl.h, you find:

/* I2C0_SCL */
#define I2C0_SCL_GPIO0 \
	ESP32_PINMUX(0, ESP_I2CEXT0_SCL_IN, ESP_I2CEXT0_SCL_OUT)

#define I2C0_SCL_GPIO1 \
	ESP32_PINMUX(1, ESP_I2CEXT0_SCL_IN, ESP_I2CEXT0_SCL_OUT)

#define I2C0_SCL_GPIO2 \
	ESP32_PINMUX(2, ESP_I2CEXT0_SCL_IN, ESP_I2CEXT0_SCL_OUT)

#define I2C0_SCL_GPIO3 \
	ESP32_PINMUX(3, ESP_I2CEXT0_SCL_IN, ESP_I2CEXT0_SCL_OUT)

#define I2C0_SCL_GPIO4 \
	ESP32_PINMUX(4, ESP_I2CEXT0_SCL_IN, ESP_I2CEXT0_SCL_OUT)

#define I2C0_SCL_GPIO5 \
	ESP32_PINMUX(5, ESP_I2CEXT0_SCL_IN, ESP_I2CEXT0_SCL_OUT)

#define I2C0_SCL_GPIO6 \
	ESP32_PINMUX(6, ESP_I2CEXT0_SCL_IN, ESP_I2CEXT0_SCL_OUT)

#define I2C0_SCL_GPIO7 \
	ESP32_PINMUX(7, ESP_I2CEXT0_SCL_IN, ESP_I2CEXT0_SCL_OUT)

#define I2C0_SCL_GPIO8 \
	ESP32_PINMUX(8, ESP_I2CEXT0_SCL_IN, ESP_I2CEXT0_SCL_OUT)

[cbrake]

Was able to get a 6x4 keyboard matrix driver configured with the following:

/ {
	kbd_matrix: kbd-matrix {
	     compatible = "gpio-kbd-matrix";
	     row-gpios = <&gpio1 4 (GPIO_ACTIVE_LOW)>,
	                 <&gpio1 3 (GPIO_ACTIVE_LOW)>,
	                 <&gpio1 2 (GPIO_ACTIVE_LOW)>,
	                 <&gpio1 1 (GPIO_PULL_UP | GPIO_ACTIVE_LOW)>;
	     col-gpios = <&gpio1 0 GPIO_ACTIVE_LOW>,
	                 <&gpio0 13 GPIO_ACTIVE_LOW>,
	                 <&gpio0 0 GPIO_ACTIVE_LOW>,
	                 <&gpio0 4 GPIO_ACTIVE_LOW>,
	                 <&gpio0 16 GPIO_ACTIVE_LOW>,
	                 <&gpio0 5 GPIO_ACTIVE_LOW>;
	};
};

Some things to note:

• gpios above 31 are accessed in the gpio1 bank starting at 0
• gpio 34-39 are input only, and do not appear to have internal pullups available

The CONFIG_INPUT_SHELL_KBD_MATRIX_STATE=y option enables a handy shell command for dumping out the keyboard state:

[00:00:08.417,000] <inf> input: kbd-matrix state [01 -- -- -- -- --] (1)
[00:00:09.789,000] <inf> input: kbd-matrix state [-- -- -- -- -- --] (0)
[00:00:11.560,000] <inf> input: kbd-matrix state [02 -- -- -- -- --] (1)
[00:00:12.488,000] <inf> input: kbd-matrix state [-- -- -- -- -- --] (0)
[00:00:14.327,000] <inf> input: kbd-matrix state [04 -- -- -- -- --] (1)
[00:00:14.740,000] <inf> input: kbd-matrix state [-- -- -- -- -- --] (0)
[00:00:17.085,000] <inf> input: kbd-matrix state [08 -- -- -- -- --] (1)
[00:00:17.366,000] <inf> input: kbd-matrix state [-- -- -- -- -- --] (0)
[00:00:32.835,000] <inf> input: kbd-matrix state [-- 01 -- -- -- --] (1)
[00:00:33.473,000] <inf> input: kbd-matrix state [-- -- -- -- -- --] (0)
[00:00:35.790,000] <inf> input: kbd-matrix state [-- 02 -- -- -- --] (1)
[00:00:36.162,000] <inf> input: kbd-matrix state [-- -- -- -- -- --] (0)
[00:00:37.389,000] <inf> input: kbd-matrix state [-- 04 -- -- -- --] (1)
[00:00:37.705,000] <inf> input: kbd-matrix state [-- -- -- -- -- --] (0)
[00:00:40.140,000] <inf> input: kbd-matrix state [-- 08 -- -- -- --] (1)
[00:00:40.538,000] <inf> input: kbd-matrix state [-- -- -- -- -- --] (0)
[00:01:01.959,000] <inf> input: kbd-matrix state [-- -- 01 -- -- --] (1)
[00:01:02.383,000] <inf> input: kbd-matrix state [-- -- -- -- -- --] (0)
[00:01:04.518,000] <inf> input: kbd-matrix state [-- -- 02 -- -- --] (1)
[00:01:04.915,000] <inf> input: kbd-matrix state [-- -- -- -- -- --] (0)
[00:01:05.544,000] <inf> input: kbd-matrix state [-- -- 04 -- -- --] (1)
[00:01:05.865,000] <inf> input: kbd-matrix state [-- -- -- -- -- --] (0)
[00:01:06.447,000] <inf> input: kbd-matrix state [-- -- 08 -- -- --] (1)
[00:01:06.758,000] <inf> input: kbd-matrix state [-- -- -- -- -- --] (0)
[00:01:22.857,000] <inf> input: kbd-matrix state [-- -- -- 01 -- --] (1)
[00:01:23.306,000] <inf> input: kbd-matrix state [-- -- -- -- -- --] (0)
[00:01:23.868,000] <inf> input: kbd-matrix state [-- -- -- 02 -- --] (1)
[00:01:24.347,000] <inf> input: kbd-matrix state [-- -- -- -- -- --] (0)
[00:01:24.782,000] <inf> input: kbd-matrix state [-- -- -- 04 -- --] (1)
[00:01:25.129,000] <inf> input: kbd-matrix state [-- -- -- -- -- --] (0)
[00:01:25.615,000] <inf> input: kbd-matrix state [-- -- -- 08 -- --] (1)
[00:01:25.962,000] <inf> input: kbd-matrix state [-- -- -- -- -- --] (0)
[00:01:44.944,000] <inf> input: kbd-matrix state [-- -- -- -- 01 --] (1)
[00:01:45.301,000] <inf> input: kbd-matrix state [-- -- -- -- -- --] (0)
[00:01:45.810,000] <inf> input: kbd-matrix state [-- -- -- -- 02 --] (1)
[00:01:46.142,000] <inf> input: kbd-matrix state [-- -- -- -- -- --] (0)
[00:01:46.568,000] <inf> input: kbd-matrix state [-- -- -- -- 04 --] (1)
[00:01:46.869,000] <inf> input: kbd-matrix state [-- -- -- -- -- --] (0)
[00:01:47.317,000] <inf> input: kbd-matrix state [-- -- -- -- 08 --] (1)
[00:01:47.587,000] <inf> input: kbd-matrix state [-- -- -- -- -- --] (0)
[00:01:58.452,000] <inf> input: kbd-matrix state [-- -- -- -- -- 01] (1)
[00:01:58.809,000] <inf> input: kbd-matrix state [-- -- -- -- -- --] (0)
[00:01:59.127,000] <inf> input: kbd-matrix state [-- -- -- -- -- 02] (1)
[00:01:59.464,000] <inf> input: kbd-matrix state [-- -- -- -- -- --] (0)
[00:01:59.784,000] <inf> input: kbd-matrix state [-- -- -- -- -- 04] (1)
[00:02:00.074,000] <inf> input: kbd-matrix state [-- -- -- -- -- --] (0)
[00:02:00.382,000] <inf> input: kbd-matrix state [-- -- -- -- -- 08] (1)
[00:02:00.729,000] <inf> input: kbd-matrix state [-- -- -- -- -- --] (0)