ESP32-P4X-Function-EV-Board

Overview

ESP32-P4X-Function-EV-Board is an evaluation board from Espressif built around the ESP32-P4 SoC, a high-performance dual-core RISC-V MCU. The board pairs the bare SoC with 16 MB of on-board flash and 8 MB of external PSRAM, and exposes USB Serial/JTAG, MIPI CSI/DSI, SD card and expansion headers for application development. For more information, check ESP32-P4X-Function-EV-Board [6].

This board is the ESP32-P4-Function-EV-Board respun with ESP32-P4 silicon revision v3.1 (the v3.x family). The v3.x parts add the VDD_HP_1 power rail and require a different PCB and a build targeting revision v3.x (different ROM and register layout) than the older v1.3 board; the Zephyr board configuration targets revision v3.1 with the HP cores clocked at 400 MHz. For the older v1.3 board, use esp32p4_function_ev_board instead.

Hardware

ESP32-P4X-Function-EV-Board ships with:

  • ESP32-P4 SoC (silicon revision v3.1) paired with 16 MB on-board flash and 8 MB external PSRAM

  • USB-C connector wired to the on-chip USB Serial/JTAG controller

  • MIPI CSI camera connector

  • MIPI DSI display connector

  • microSD card slot

  • 10/100 Mbps Ethernet RJ45 port driven by the on-chip EMAC and an IP101 PHY over RMII

  • Boot and reset buttons

  • Expansion headers exposing UART, I2C, SPI and GPIO

ESP32-P4 Features

ESP32-P4 is Espressif’s high-performance MCU featuring a dual-core 32-bit RISC-V high-performance (HP) processor running up to 400 MHz, plus a low-power (LP) 32-bit RISC-V coprocessor. It targets human-machine interface (HMI) and edge-computing applications with an integrated L2 cache, high-bandwidth memory interfaces, and rich connectivity options.

ESP32-P4 includes the following features:

  • Dual core 32-bit RISC-V HP processor with a clock speed of up to 400 MHz

  • 32-bit RISC-V LP processor with a clock speed of up to 40 MHz

  • 768 KB of high-performance SRAM

  • 32 KB of low-power SRAM

  • 128 KB of ROM

  • L1 instruction and data caches plus a unified L2 cache

  • Up to 64 MB of external PSRAM in HEX or octal mode

  • Up to 16 MB of external flash

Digital interfaces:

  • 55 programmable GPIOs

  • 5x UART

  • 1x Low-power (LP) UART

  • 2x General purpose SPI

  • 2x I2C

  • 1x Low-power (LP) I2C

  • 3x I2S

  • 1x SDIO 3.0 host controller with 2 slots

  • 1x USB 2.0 OTG High-Speed (HS) with embedded PHY

  • 1x USB Serial/JTAG controller

  • 1x 10/100 Mbit Ethernet MAC with RMII interface

  • 1x MIPI-CSI camera interface

  • 1x MIPI-DSI display interface

  • 1x JPEG codec

  • 1x 2D Pixel Processing Accelerator (PPA)

  • LED PWM controller, up to 8 channels

  • 2x Motor control PWM (MCPWM)

  • 3x TWAI controller, compatible with ISO 11898-1 (CAN Specification 2.0)

  • 1x Pulse counter

  • 1x Remote control peripheral

  • General DMA controller (GDMA) over AHB and AXI buses

  • Event task matrix (ETM)

Analog interfaces:

  • 1x 12-bit SAR ADC

  • 1x temperature sensor

Timers:

  • 1x 52-bit system timer

  • 2x 54-bit general-purpose timers

  • 2x Watchdog timers

Low Power:

  • Multiple power modes designed for typical scenarios: Active, Modem-sleep, Light-sleep, Deep-sleep

  • 4-channel programmable on-chip LDO regulators

  • Power Management Unit (PMU) with dedicated retention DMA

Security:

  • Secure boot

  • Flash encryption

  • Cryptographic hardware acceleration: AES-128/256, SHA, RSA, ECC, HMAC, Digital signature, ECDSA

  • True random number generator (TRNG)

  • Key manager

Low-Power CPU (LP CORE)

The ESP32-P4 SoC has a Low-Power (LP) 32-bit RISC-V coprocessor in addition to the dual HP cores. The LP Core features ultra low power consumption, an interrupt controller, a debug module and a system bus interface for memory and peripheral access.

The LP Core is in sleep mode by default. It has two application scenarios:

  • Power insensitive scenario: When the HP cores are active, the LP Core can assist with some speed and efficiency-insensitive controls and computations.

  • Power sensitive scenario: When the HP cores are in the power-down state to save power, the LP Core can be woken up to handle some external wake-up events.

The LP Core support is fully integrated with Sysbuild (System build). The user can enable the LP Core by adding the following configuration to the project:

CONFIG_ESP32_ULP_COPROC_ENABLED=y

See Low-Power CPU (LP CORE) folder as code reference.

For more information, check the ESP32-P4 Datasheet [1] or the ESP32-P4 Technical Reference Manual [2].

Supported Features

The esp32p4x_function_ev_board board supports the hardware features listed below.

on-chip / on-board
Feature integrated in the SoC / present on the board.
2 / 2
Number of instances that are enabled / disabled.
Click on the label to see the first instance of this feature in the board/SoC DTS files.
vnd,foo
Compatible string for the Devicetree binding matching the feature.
Click on the link to view the binding documentation.

Programming and Debugging

The esp32p4x_function_ev_board board supports the runners and associated west commands listed below.

flash debug

Simple Boot

The board could be loaded using the single binary image, without 2nd stage bootloader. It is the default option when building the application without additional configuration.

Note

Simple boot does not provide any security features nor OTA updates.

MCUboot Bootloader

User may choose to use MCUboot bootloader instead. In that case the bootloader must be built (and flashed) at least once.

There are two options to be used when building an application:

  1. Sysbuild

  2. Manual build

Note

User can select the MCUboot bootloader by adding the following line to the board default configuration file.

CONFIG_BOOTLOADER_MCUBOOT=y

Sysbuild

The sysbuild makes possible to build and flash all necessary images needed to bootstrap the board with the ESP32 SoC.

To build the sample application using sysbuild use the command:

west build -b <board> --sysbuild samples/hello_world

By default, the ESP32 sysbuild creates bootloader (MCUboot) and application images. But it can be configured to create other kind of images.

Build directory structure created by sysbuild is different from traditional Zephyr build. Output is structured by the domain subdirectories:

build/
├── hello_world
│   └── zephyr
│       ├── zephyr.elf
│       └── zephyr.bin
├── mcuboot
│    └── zephyr
│       ├── zephyr.elf
│       └── zephyr.bin
└── domains.yaml

Note

With --sysbuild option the bootloader will be re-build and re-flash every time the pristine build is used.

For more information about the system build please read the Sysbuild (System build) documentation.

Manual Build

During the development cycle, it is intended to build & flash as quickly possible. For that reason, images can be built one at a time using traditional build.

The instructions following are relevant for both manual build and sysbuild. The only difference is the structure of the build directory.

Note

Remember that bootloader (MCUboot) needs to be flash at least once.

Build and flash applications as usual (see Building an Application and Run an Application for more details).

# From the root of the zephyr repository
west build -b <board> samples/hello_world

The usual flash target will work with the board configuration. Here is an example for the Hello World application.

# From the root of the zephyr repository
west build -b <board> samples/hello_world
west flash

Note

On targets that expose the built-in USB Serial/JTAG controller, the chip can stay in download mode after west flash and will not boot the new image until it is power cycled. If that happens, flash with a watchdog reset so the chip restarts on its own:

west flash --reset-type watchdog-reset

Faster Flashing

To speed up the development cycle, --esp-skip-flashed skips writing the image when the binary already in flash matches the one being flashed, verified with an MD5 check on the device:

west flash --esp-skip-flashed

For an even faster reflash, --esp-diff writes only the regions that differ from the previously flashed image. It compares against a locally cached copy rather than reading the device, so use it only when the flash was not modified by another tool, board, or manual write since the last west flash:

west flash --esp-diff

Progress output can be suppressed for cleaner logs, which is useful in CI:

west flash --esp-no-progress

Open the serial monitor using the following command:

west espressif monitor

After the board has automatically reset and booted, you should see the following message in the monitor:

***** Booting Zephyr OS vx.x.x-xxx-gxxxxxxxxxxxx *****
Hello World! <board>

Debugging

OpenOCD Debugging

Espressif chips require a custom OpenOCD build with ESP32-specific patches. Download the latest release from OpenOCD for ESP32 [3].

For detailed JTAG setup instructions, see JTAG debugging for ESP32 [5].

Zephyr Thread Awareness

OpenOCD supports Zephyr RTOS thread awareness, allowing GDB to:

  • List all threads with info threads

  • Display thread names, priorities, and states

  • Switch between thread contexts

  • Show backtraces for any thread

Requirements:

Example:

# From the root of the zephyr repository
west build -b <board> samples/hello_world -- -DCONFIG_DEBUG_THREAD_INFO=y -DOPENOCD=<path/to/bin/openocd> -DOPENOCD_DEFAULT_PATH=<path/to/openocd/share/openocd/scripts>
west debug

Using a Custom OpenOCD

The Zephyr SDK includes a bundled OpenOCD, but it may not have ESP32 support. To use the Espressif OpenOCD, specify the path when building:

# From the root of the zephyr repository
west build -b <board> samples/hello_world -- -DOPENOCD=/path/to/openocd -DOPENOCD_DEFAULT_PATH=/path/to/openocd/scripts
west debug

References