Esp32 P4

ESP32-P4 chip capabilities

This skill is the chip layer, not a board layer. A board skill (e.g. m5stack-tab5) tells you what's wired to what on one specific product; this skill tells you what the ESP32-P4 silicon itself can do — the peripherals, multimedia hardware, low-power modes, memory options, and concurrency model that are the same on every ESP32-P4 board regardless of vendor. Read a board's own skill first for pin numbers and I2C addresses, then come here when the user wants to go deeper on a capability than "call the vendor's high-level library and move on" — e.g. driving the MIPI camera pipeline, encoding H.264 in hardware, using the LP core while the main system sleeps, or getting real throughput out of USB HS OTG.

The one thing every ESP32-P4 user needs to know: no radio, ever

Unlike every other current ESP32 variant, the P4 has zero wireless hardware — no WiFi, no Bluetooth, no Thread/Zigbee/802.15.4. This isn't a stripped-down SKU; the chip was designed as a high-performance applications/HMI processor and pairs with a separate radio chip (an ESP32-C6 on M5Stack's Tab5 and Stamp-P4, most commonly) over SDIO or SPI when a project needs wireless. If a user asks "why won't WiFi.begin() compile/link" or "how do I get WiFi on my P4 board," the answer is always "it needs a companion radio chip and a host-side driver (ESP-Hosted or similar) talking to it" — not a missing library or wrong board setting. See that board's own skill (e.g. the m5stack-tab5 skill's "WiFi needs pin setup" section) for the actual wiring/init pattern on a specific product.

Not classic ESP32, not S2/S3, not C3/C6/C5, not H2

M5Stack (and the ESP32 family generally) spans several very different chips that are easy to conflate. Get this wrong and code silently targets the wrong architecture or assumes a peripheral that doesn't exist.

If the user's board pairs an ESP32-P4 with a companion radio chip (the case for every current M5Stack P4 board), that companion chip is out of this skill's scope — for the ESP32-C6 specifically, see the esp32-c6 skill in this same plugin.

Quick specs

• HP (High-Performance) cores: 2× 32-bit RISC-V, 5-stage pipeline, up to 400MHz, single-precision FPU, PIE AI/DSP instruction extensions (see references/memory-concurrency-ai.md)
• LP (Low-Power) core: 1× 32-bit RISC-V, 2-stage pipeline, up to 40MHz — a real coprocessor that can run independently, including while the HP cores are active, not just during sleep (see references/power-sleep-lp.md)
• On-chip memory: 768KB HP L2 SRAM, 128KB HP ROM, 32KB LP SRAM, 16KB LP ROM, 8KB zero-wait-state TCM
• PSRAM: not on the bare die — many module variants embed it in-package (e.g. ESP32-P4NRW16/ESP32-P4NRW32 = 16MB/32MB Octal, 1.8V); check the specific module before assuming a size. M5Stack's Tab5 uses the 32MB variant.
• Flash: external only, SPI/Dual/Quad/QPI, up to 64MB
• GPIO: up to 55 pins on the bare chip (5 are strapping pins); 15 are LP/RTC-capable (usable as deep-sleep wake sources and by the LP core) — how many are actually free depends on the module and the board, check that board's references/pinout.md
• USB: three independent USB-capable blocks sharing no pins with each other — a true USB 2.0 High-Speed OTG (480Mbps, integrated PHY), a separate USB 2.0 Full-Speed OTG (also integrated PHY), and a USB-Serial-JTAG controller. This is a bigger deal than it sounds — see references/usb.md, most USB confusion on this chip traces back to which of the three a board's connector(s) are wired to.
• Display/camera: MIPI-DSI (display out) and MIPI-CSI (camera in) with an integrated ISP, plus legacy parallel (DVP) display and camera interfaces for non-MIPI panels/sensors — up to 1080p on both. See references/multimedia-vision.md.
• Hardware video/image codecs: JPEG encode and decode (one at a time, not simultaneously), and H.264 hardware encode (software decode only) up to 1080p30 — plus a PPA (Pixel Processing Accelerator) and 2D-DMA for GPU-free image scaling/rotation/blending. See references/multimedia-vision.md.
• Wireless: none — see "no radio, ever" above
• Ethernet: one MAC (EMAC), RMII mode — needs an external PHY chip, the P4 doesn't have one built in
• Storage interfaces: SDIO/SD/MMC host controller, plus the usual SPI flash and (via GPIO) SD-SPI fallback
• Other peripherals: 5 UART + 1 LP UART, 4 SPI + 1 LP SPI, 2 I2C + 1 LP I2C + 1 analog I2C, 1 I3C controller, 3 I2S + 1 LP I2S, 1 TWAI/CAN, 1 RMT, 1 LEDC, 1 MCPWM, 1 PCNT, 1 PARLIO (parallel IO), 1 BitScrambler, 14 touch channels, 2 ADC controllers (8+6 channels), internal temperature sensor, VAD (voice activity detection) unit — full detail and typical use cases in references/peripherals.md
• Security: Secure Boot, Flash Encryption (XTS-AES), AES/ECC/HMAC/RSA/SHA accelerators, RSA/ECDSA digital-signature peripherals, TRNG, a Key Manager with SRAM-PUF-derived HUK, and permission-control (PMS) hardware access protection — not detailed further in this skill, see ESP-IDF's security guides if the user needs this
• Package: QFN104 (10×10mm), -40°C to 85°C

Peripheral capability map

Full detail, with typical use cases and gotchas, is in references/peripherals.md. Quick index of what's covered there: RMT, LEDC, I2S, ADC, capacitive touch, PCNT, MCPWM, TWAI, SDMMC/SD-SPI/SDIO host, GPTimer, Ethernet MAC, I3C, PARLIO, BitScrambler, and the multi-instance UART/SPI/I2C story.

Multimedia and vision: the P4's headline feature

MIPI-CSI camera input with an integrated ISP, MIPI-DSI display output, hardware JPEG encode/decode, hardware H.264 encode, and the PPA/2D-DMA image accelerators are what actually distinguish this chip from an ESP32-S3 for most projects — this is why M5Stack picked it for the Tab5's 1280x720 display and camera. Full detail, including throughput numbers and the encode/decode asymmetry (hardware JPEG both ways, but H.264 hardware-encode / software-decode only), is in references/multimedia-vision.md.

Power management: two very different low-power stories

Light sleep / deep sleep and their wake sources work broadly like other ESP32 chips, but the P4's LP core is not a limited ULP-FSM-style coprocessor — it's a genuine RISC-V core with its own UART/I2C/SPI/I2S/GPIO peripherals, a debug module, and an interrupt controller, and it's capable of running while the HP cores are fully active, not just during sleep. Full detail in references/power-sleep-lp.md — read this before telling a user "just call esp_deep_sleep_start()" if they actually want an always-on background task offloaded from the HP cores.

USB: three controllers, not two

The P4 doubles down on USB relative to the S3 — see "Quick specs" above. Full detail on which controller does what, default pin assignments, and the current-firmware limitation that only one of the two OTG controllers can be in Host mode at a time, is in references/usb.md.

Memory, concurrency, and on-device AI

In-package PSRAM variants and flash config, HP-core task pinning, and the PIE (Processor Instruction Extensions) SIMD instructions that back esp-dsp/esp-dl/esp-tflite-micro on this chip (P4 doesn't share the S3's Xtensa TIE-based SIMD — it's a different ISA extension with its own instruction prefix) are in references/memory-concurrency-ai.md.

Which M5Stack boards use this chip

Tab5 is confirmed ESP32-P4-based (paired with an ESP32-C6 radio co-processor — see the m5stack-tab5 skill). Stamp-P4 (with its "AddOn C6 For P4") is a likely match by name, not yet independently verified. No other current M5Stack Controller uses this chip.

Official resources

• Datasheet: https://documentation.espressif.com/esp32-p4_datasheet_en.html
• Product page: https://www.espressif.com/en/products/socs/esp32-p4
• ESP-IDF API reference (esp32p4 target): https://docs.espressif.com/projects/esp-idf/en/stable/esp32p4/api-reference/index.html
• Sleep modes: https://docs.espressif.com/projects/esp-idf/en/stable/esp32p4/api-reference/system/sleep_modes.html
• LP Core / ULP programming: https://docs.espressif.com/projects/esp-idf/en/stable/esp32p4/api-reference/system/ulp.html
• USB Host (DWC_OTG, both OTG controllers): https://docs.espressif.com/projects/esp-idf/en/stable/esp32p4/api-reference/peripherals/usb_host.html
• USB Serial/JTAG console: https://docs.espressif.com/projects/esp-idf/en/stable/esp32p4/api-guides/usb-serial-jtag-console.html
• Camera controller / ISP driver: https://docs.espressif.com/projects/esp-idf/en/stable/esp32p4/api-reference/peripherals/camera_driver.html
• JPEG encoder/decoder: https://docs.espressif.com/projects/esp-idf/en/stable/esp32p4/api-reference/peripherals/jpeg.html
• H.264 component (esp-h264-component) usage guide: https://developer.espressif.com/blog/2025/07/esp-h264-use-tips/
• PIE (AI/DSP instruction extensions) introduction: https://developer.espressif.com/blog/2024/12/pie-introduction/
• Hardware design guidelines (schematic checklist, USB PHY/pin notes): https://docs.espressif.com/projects/esp-hardware-design-guidelines/en/latest/esp32p4/schematic-checklist-esp32p4.html

Working with the user

• If they're getting compile/link errors from WiFi/BLE code copy-pasted from an S3/C3/C6 project, the "no radio, ever" section above is almost certainly the cause — check whether their board has a companion radio chip and whether they're using its host-side driver, not a missing library.
• If they're getting compile/link errors from code copy-pasted for a different ESP32 variant otherwise, check the "Not classic ESP32..." table above first — RISC-V-vs-Xtensa and missing-peripheral mismatches are the most common cause.
• If they ask for USB Host functionality and it silently doesn't work alongside another USB feature, check references/usb.md — the "only one OTG controller can be Host at a time" current-software limitation is a common surprise.
• If they want something to keep running while the HP cores sleep or want to offload a lightweight background task without spending an HP-core FreeRTOS task on it, point them at the LP core in references/power-sleep-lp.md rather than assuming it's ULP-FSM-limited like older chips.
• If they're doing camera/video work and performance doesn't match expectations, check references/multimedia-vision.md for the actual hardware-vs-software encode/decode split (H.264 decode is software-only and much slower than encode) before assuming their code is wrong.
• This is chip-level guidance, cross-checked against Espressif's own ESP-IDF and datasheet docs at time of writing — but ESP32-P4 support across ESP-IDF/Arduino/PlatformIO is newer and moves faster than on the established Xtensa chips. If the user hits a compile error on a specific function signature or a "target not supported" error, point them at the current ESP-IDF docs for their exact version rather than assuming this file is byte-exact.