Programming the ESP32-S3 on Arduino UNO R4 WiFi: WiFiS3, USB and Firmware

The Arduino UNO R4 WiFi contains an ESP32-S3, but it does not normally work like an ESP32-S3 development board.

Your standard Arduino sketch runs on the Renesas RA4M1. The onboard ESP32-S3-MINI-1-N8 acts as a secondary processor that provides:

• Wi-Fi;
• Bluetooth LE;
• USB-to-serial bridging;
• RA4M1 programming support;
• network services used by WiFiS3;
• TLS certificate storage used by secure networking.

You can program the ESP32-S3 directly, but doing so replaces Arduino’s connectivity firmware. Once that firmware is overwritten, normal WiFiS3 operation and even the usual UNO R4 WiFi USB/programming path may stop working until you restore the official bridge firmware.

This guide explains the architecture first, then covers normal WiFiS3 use, firmware-version checks, Arduino’s Firmware Updater, the ESP header, ESP download mode, direct ESP32-S3 flashing, USB routing and recovery.

UNO R4 WiFi Architecture at a Glance

Function	RA4M1	ESP32-S3
Normal Arduino sketch	Yes	No, not by default
CPU	Arm Cortex-M4 at 48 MHz	Dual-core Xtensa LX7 up to 240 MHz
Main user GPIO	Yes, 5 V UNO pins	Only limited direct access through ESP header/test points
Wi-Fi	Uses ESP32-S3 through firmware interface	Owns Wi-Fi radio
Bluetooth LE	Uses ESP32-S3	Owns BLE radio
USB-C bridge	Normally programmed through ESP32-S3	Acts as USB bridge by default
Direct programming	Normal Arduino IDE target	Possible, advanced
Operating voltage	5 V	3.3 V
ESP flash	N/A	8 MB module flash
ESP SRAM	N/A	512 kB internal SRAM

The ESP32-S3 Is Normally a Connectivity Processor

The key architecture is:

This is why the UNO R4 WiFi is not equivalent to an ESP32-S3 DevKitC-1.

On a native ESP32-S3 board:

On the R4 WiFi, your normal application sits one processor away from the radio.

What WiFiS3 Actually Does

UNO R4 WiFi networking is normally accessed with:

The RA4M1-side library sends commands to the ESP32-S3 connectivity firmware.

So when you write:

the RA4M1 is not directly configuring a Wi-Fi peripheral inside itself. It is asking the ESP32-S3 firmware to perform the network operation.

Basic WiFiS3 Connection Example

Check Whether the ESP32-S3 Firmware Is Responding

A useful first diagnostic is:

If this returns WL_NO_MODULE, possible causes include:

• connectivity firmware missing;
• ESP32-S3 firmware corrupted;
• custom firmware previously flashed to the ESP32-S3;
• communication failure between the RA4M1 and ESP32-S3.

Read the ESP32-S3 Firmware Version

The current WiFiS3 library exposes:

Example:

The library also includes a numeric firmware-version API in current releases.

Why Connectivity Firmware Updates Matter

The ESP32-S3 firmware is not merely a basic serial bridge.

Arduino has continued adding and fixing features including:

• Wi-Fi functions;
• Bluetooth support;
• TLS certificate handling;
• OTA behaviour;
• network time support;
• ping functionality;
• USB/HID behaviour;
• firmware-management features.

If networking examples behave differently from current documentation, checking the bridge firmware version is sensible.

Normal Firmware Update: Arduino IDE

The safest update method is Arduino IDE 2.

Arduino provides the connectivity Firmware Updater from:

The normal workflow is:

1. connect the UNO R4 WiFi with a data-capable USB cable;
2. close Serial Monitor;
3. open Tools → Firmware Updater;
4. select UNO R4 WiFi;
5. check for updates;
6. install the current connectivity firmware.

Arduino IDE 2.2.1 and later include the UNO R4 WiFi update workflow.

Arduino Cloud Can Also Update the Firmware

When an UNO R4 WiFi is added to Arduino Cloud, the connectivity-module firmware can be updated as part of the board setup process.

This is useful because the same ESP32-S3 is involved in:

• Arduino Cloud connectivity;
• USB board detection;
• networking.

What Firmware Is on the ESP32-S3?

Arduino publishes the connectivity firmware in the open-source:

project.

The firmware itself is built using Arduino’s ESP32 platform and turns the ESP32-S3 into a combined:

• USB bridge;
• Wi-Fi host;
• connectivity processor;
• firmware-management endpoint.

As of September 2026, Arduino’s latest public bridge release is 0.6.0. Future versions may of course change, so use the Firmware Updater rather than hard-coding a version assumption into your project.

USB-C Is Normally Connected Through the ESP32-S3

When you upload a normal UNO R4 WiFi sketch, the USB-C connection normally reaches the RA4M1 through the ESP32-S3 bridge firmware.

That arrangement lets one USB-C connector handle:

• serial communication;
• board detection;
• RA4M1 programming;
• ESP32-S3 firmware management.

Why Custom ESP32 Firmware Can Break Normal Uploading

If you replace the bridge firmware with a generic ESP32-S3 sketch, you remove the code responsible for bridging the computer to the RA4M1.

The board may then:

• appear as a generic ESP32-S3;
• stop appearing as an UNO R4 WiFi;
• stop uploading normal RA4M1 sketches through the default route;
• lose WiFiS3 connectivity;
• lose normal serial bridging.

This behaviour is expected. It does not necessarily mean the board is permanently damaged.

The ESP Header

The 6-pin header near the reset/USB area exposes direct ESP32-S3 signals.

Arduino documents the pins as:

Header pin	Signal	Purpose
1	ESP_IO42	MTMS / debugging
2	ESP_IO41	MTDI / debugging
3	ESP_TXD0	ESP32-S3 UART transmit
4	ESP_DOWNLOAD	ESP boot/download control
5	ESP_RXD0	ESP32-S3 UART receive
6	GND	Ground

This header is intended for advanced access to the ESP32-S3.

ESP_DOWNLOAD Pin

The most important pin for firmware recovery is:

Shorting ESP_DOWNLOAD to GND while connecting/powering the board places the ESP32-S3 into its ROM download mode.

In that state, the computer should detect an Espressif USB programming/debug device rather than the normal UNO bridge interface.

Entering ESP Download Mode Manually

The manual process is:

1. disconnect USB power;
2. short ESP_DOWNLOAD to GND on the ESP header;
3. connect the USB-C cable;
4. wait for the ESP32-S3 USB device to enumerate;
5. remove the short once download mode has been entered.

The exact OS device name varies. On many systems it appears as an Espressif USB JTAG/serial debug device.

Do You Need to Enter Download Mode for Normal Arduino Uploads?

No.

Normal RA4M1 Arduino sketches should upload through the standard UNO R4 WiFi board selection without touching the ESP header.

ESP download mode is mainly for:

• restoring broken connectivity firmware;
• flashing custom ESP32-S3 firmware;
• advanced ESP32 debugging.

Directly Programming the ESP32-S3

Direct ESP32-S3 programming is possible because the module is a real ESP32-S3 and Arduino exposes its download/debug interface.

You can therefore flash it with normal ESP32 tools when it is in download mode.

Possible development environments include:

• Arduino-ESP32;
• ESP-IDF;
• esptool;
• espflash.

However, the physical board is still not equivalent to an ESP32-S3 DevKitC because only a small subset of ESP32 pins is conveniently exposed.

Why Direct ESP32 Programming Is Mostly Experimental

The UNO R4 WiFi is designed around cooperation between two MCUs.

If your goal is simply:

a Nano ESP32 or ESP32-S3 DevKitC is usually a cleaner development platform.

Direct programming of the R4’s ESP32-S3 makes the most sense when you specifically want to investigate:

• dual-MCU architectures;
• custom RA4M1-to-ESP protocols;
• the Arduino bridge implementation;
• USB routing;
• custom connectivity firmware.

Custom ESP32 Firmware Replaces WiFiS3 Support

Once you flash a normal ESP32-S3 sketch, code such as:

on the RA4M1 will no longer have the official connectivity firmware to talk to.

So a custom ESP sketch and normal WiFiS3 cannot simply coexist unless your custom firmware reimplements the protocol expected by the RA4M1 libraries.

Direct ESP32 GPIO Access Is Limited by Board Routing

The ESP32-S3 module has many internal GPIO capabilities, but the UNO R4 WiFi PCB does not expose them like a conventional ESP32 development board.

The accessible ESP header focuses on:

• UART;
• download control;
• debug signals.

Most normal UNO shield pins belong to the RA4M1, not the ESP32-S3.

The UNO Header Is Not Connected Directly to ESP32-S3 GPIO

This is another important misconception.

For example, when your R4 sketch does:

it is driving a RA4M1 GPIO.

The ESP32-S3 is not directly controlling the normal UNO D0-D13 pins.

Communication Between the Two MCUs

The board includes logic-level translation between the 5 V RA4M1 side and the 3.3 V ESP32-S3 side.

Arduino’s bridge firmware uses serial-style internal communication to implement networking commands and USB bridging.

This is why the voltage difference between the MCUs does not require the user to add external level shifters for the onboard communication path.

USB Routing to the RA4M1 Directly

The UNO R4 WiFi hardware includes analog USB switches that can bypass the ESP32-S3 and route USB directly to the RA4M1.

Arduino documents the routing control through:

Driving this control appropriately switches the USB path from the ESP32-S3 bridge to direct RA4M1 USB.

This is an advanced board-level feature and is not required for normal use.

SJ1 USB Bypass

The board also includes solder jumper SJ1.

Soldering SJ1 permanently routes USB directly to the RA4M1, bypassing the ESP32-S3 bridge.

This can be useful for specialised native-USB experiments but changes the standard board behaviour.

Do not solder it merely to solve an ordinary upload problem.

Normal RA4M1 Programming Through the Bridge

In standard configuration, the ESP32-S3 bridge handles the PC-facing USB interface while Arduino tooling uploads the compiled Renesas firmware to the RA4M1.

The user experience remains:

even though the internal route includes the ESP32-S3.

Bridge Firmware and USB Serial

The open-source bridge code describes the ESP32-S3 as a:

So the same firmware is responsible for more than wireless networking.

This explains why a damaged or replaced connectivity firmware can affect USB behaviour even when your RA4M1 sketch itself is perfectly valid.

Secure Wi-Fi and TLS Certificates

The current bridge firmware packages a root CA certificate bundle used by secure networking support.

UNO R4 WiFi secure client examples use:

and rely on the connectivity firmware for parts of the TLS/network implementation.

This is another reason firmware updates can matter even if ordinary unencrypted Wi-Fi already works.

Firmware Updater vs Direct ESP Flashing

Method	Use it when
Arduino IDE Firmware Updater	Normal firmware maintenance
Arduino Cloud	Board provisioning and normal connectivity updates
Firmware Uploader CLI	Automated/command-line official update workflow
espflash recovery	Board cannot be identified normally because bridge firmware is missing/broken
esptool/ESP-IDF	Advanced custom ESP32-S3 development

Restoring the Official ESP32-S3 Firmware

If the ESP32-S3 has been overwritten or corrupted and the normal Firmware Updater cannot identify the board, Arduino documents a recovery process using espflash.

The high-level process is:

1. enter ESP download mode by shorting ESP_DOWNLOAD to GND during USB connection;
2. download Arduino’s official UNO R4 WiFi recovery package;
3. run the included espflash command;
4. write the combined bridge firmware binary at address 0x0;
5. disconnect the board;
6. remove the ESP_DOWNLOAD/GND short;
7. reconnect normally.

Official Recovery Command Pattern

The recovery packages use a command equivalent to:

Use the binary supplied by Arduino’s current recovery package rather than an arbitrary ESP32-S3 firmware file.

Why the Recovery Image Starts at Address 0x0

Arduino’s release build combines the required ESP32 firmware pieces into one firmware blob.

This includes the components needed to restore the connectivity processor as an UNO R4 WiFi bridge rather than as a generic ESP32-S3.

The packaged image can therefore be written from:

using Arduino’s recovery instructions.

Building the Bridge Firmware Yourself

Arduino’s open-source repository can also be built manually.

The build process uses a patched Arduino-ESP32 environment and Arduino CLI to generate the bridge binaries.

This is primarily useful for developers who want to:

• study the bridge code;
• modify connectivity behaviour;
• test changes to USB handling;
• build custom firmware versions.

For normal board maintenance, use the prebuilt official firmware instead.

Direct esptool-Style Flash Layout

The bridge project’s development instructions also show the conventional multi-file ESP32 flashing layout, with files such as:

• bootloader;
• partition table;
• boot application data;
• main firmware.

Normal users do not need to reproduce this layout manually because Arduino packages a combined recovery image.

When the Board Appears as a Generic ESP32

This usually indicates that the ESP32-S3 is running something other than the expected UNO R4 bridge firmware or is left in download mode.

Check:

1. ESP_DOWNLOAD is not still shorted to GND;
2. disconnect and reconnect USB;
3. press RESET;
4. try Arduino Firmware Updater;
5. if the board cannot be identified, use the official espflash recovery procedure.

When the Board Is Not Detected at All

First eliminate simple problems:

• use a known-good USB data cable;
• try another USB port;
• remove hubs;
• disconnect other unusual USB devices during firmware recovery;
• restart the IDE.

If connectivity firmware is missing, manually entering ESP download mode should still expose the ESP32-S3 ROM USB programming interface.

When WiFiS3 Reports WL_NO_MODULE

If the board uploads normally but:

check:

• bridge firmware version;
• whether the ESP32-S3 was previously custom-flashed;
• whether the firmware update completed correctly;
• current Arduino Renesas board package;
• power stability.

Firmware Version Mismatch

Current WiFiS3 examples commonly compare:

against:

If the installed version is older, update the connectivity firmware before debugging obscure network behaviour.

Do Not Confuse Board Core Version with ESP Firmware Version

There are at least two independent software layers:

Updating one does not necessarily update the other.

This is why Arduino IDE has a separate Firmware Updater.

Can the ESP32-S3 Run User Code at the Same Time as WiFiS3?

Not in the normal “upload my own independent ESP32 sketch” sense.

The ESP32-S3 must run Arduino’s connectivity firmware for the standard WiFiS3 interface to work.

You could theoretically modify Arduino’s open-source bridge firmware and add your own functionality, but then you are maintaining custom connectivity firmware rather than simply running two ordinary Arduino sketches.

Can the RA4M1 and ESP32-S3 Run Two Independent Arduino Sketches?

Hardware-wise, both are programmable processors.

But the board’s standard architecture does not provide an official workflow where:

Once you replace the ESP bridge firmware, you become responsible for the communication protocol and USB/network behaviour.

When Direct ESP32-S3 Programming Makes Sense

It is useful if you want to:

• learn how the two processors communicate;
• build a custom coprocessor protocol;
• modify the USB bridge;
• experiment with JTAG;
• develop specialised firmware for a fixed R4-based product.

When You Should Use Nano ESP32 Instead

If your actual objective is:

• run Arduino code directly on ESP32-S3;
• use native ESP-NOW;
• use ESP-IDF;
• use ESP32-S3 PSRAM;
• control many ESP32 GPIOs;
• use the ESP32 as the only MCU;

the Arduino Nano ESP32 is a much cleaner platform.

See our UNO R4 WiFi vs Nano ESP32 comparison for the architectural difference.

When You Should Use ESP32-S3 DevKitC Instead

If you want the Espressif reference-development-board style with maximum native ESP32 exposure, use an ESP32-S3 DevKitC-1.

It gives direct access to:

• many ESP32 GPIOs;
• native USB;
• Wi-Fi;
• BLE;
• PSRAM/flash module variants;
• ESP-IDF;
• Arduino-ESP32.

See our UNO R4 WiFi vs ESP32-S3 DevKitC comparison.

UNO R4 WiFi’s Real Strength

The dual-MCU arrangement makes most sense when you use each processor for its intended role:

You get a modern connected Arduino without forcing a 3.3 V ESP32 to replace the traditional 5 V UNO hardware environment.

Example: Checking Firmware Before Wi-Fi Use

Example: Normal Wi-Fi Workflow

For the overwhelming majority of UNO R4 WiFi projects, this is the correct programming model:

You do not need to upload a second sketch to the ESP32-S3.

Recovery Checklist

If direct ESP32 experimentation goes wrong:

1. disconnect USB;
2. short ESP_DOWNLOAD to GND;
3. reconnect USB;
4. confirm the ESP32-S3 programming interface appears;
5. use Arduino’s current UNO R4 WiFi recovery package;
6. flash the official combined firmware image;
7. disconnect USB;
8. remove the short;
9. reconnect normally;
10. check the board in Arduino IDE;
11. run a WiFi.firmwareVersion() test;
12. upload a normal RA4M1 sketch.

Best Practices

1. Use WiFiS3 rather than direct ESP32 programming for ordinary R4 projects.
2. Keep the ESP32-S3 connectivity firmware current.
3. Use Arduino IDE Firmware Updater for normal maintenance.
4. Do not flash the ESP32-S3 casually just because it is an ESP32.
5. Remember that custom ESP firmware replaces the USB/Wi-Fi bridge.
6. Know how to enter ESP download mode before experimenting.
7. Keep the official recovery package available if developing custom bridge firmware.
8. Use Nano ESP32 or DevKitC-1 when native ESP32-S3 development is the actual goal.
9. Do not solder SJ1 unless you intentionally want permanent direct RA4M1 USB routing.

Final Thoughts

The ESP32-S3 on the UNO R4 WiFi is powerful, but its default job is not to run your Arduino application.

The standard architecture is:

WiFiS3 lets the RA4M1 use the ESP32-S3’s networking capabilities without turning the project into a native ESP32 application.

The board does expose enough of the ESP32-S3 to let advanced users enter download mode, access UART/debug pins and replace its firmware. But once you do that, you also replace the software that makes the UNO R4 WiFi behave like an UNO R4 WiFi.

For normal projects:

For experiments with the second MCU:

Understanding that distinction removes most of the confusion around the UNO R4 WiFi’s unusual dual-MCU design.