Your first connected prototype works. Now you need a second unit for a colleague, a demonstration or a user test. You buy what looks like the same development board, install MicroPython and get a prompt on the computer. Then the Ethernet example stops working.
Before changing the application, compare the firmware on the two boards. Firmware is the software installed on the microcontroller before your Python program runs. Its build determines which board support and network features are available. A working prompt is a useful first check, but it does not show that the second unit has the same capabilities as the first.
Our own setup procedure for WIZnet Ethernet boards is short: download firmware, enter the USB bootloader, copy a UF2 file and reconnect through a serial port. Our recorded walkthrough of it used an older RP2040 Pico. This note separates that procedure from the harder question of which firmware a newer board needs.
Start with the board name, not just "Pico"
Write down the full name printed on the working board and on the replacement. Include the Ethernet controller, such as W5500, and whether the board is a Pico or a Pico 2 variant. A Raspberry Pi board connected to a separate Ethernet module is also a different arrangement from a WIZnet board with Ethernet built in.
This distinction shows up in a March 2025 MicroPython discussion. A user combining a Pico 2 W with a W5500 module reported that their modified firmware became unresponsive when the network interface was activated. The thread did not reach a solution. It shows why the complete hardware-and-firmware combination needs identifying; it does not prove every similar failure has the same cause.
For the next unit, record four things together:
- the exact board;
- the firmware download page;
- the release tag;
- the actual downloaded filename.
If the first unit works, keep a copy of its known firmware file before experimenting with a replacement. "MicroPython 1.27" alone may not identify a vendor build or its networking options.
When you hold BOOTSEL and connect USB, the computer should report the bootloader devices. That is USB recognition only, not evidence of a working Ethernet interface or application.
Check what the build is meant to provide
WIZnet publishes both a standard v1.27.0 release and a separate timeout-related release. They are not two labels for one download. The release assets distinguish board models, and the timeout release also distinguishes TOE_build and LWIP_build packages. Those use different network stacks, the software that handles network communication.
That can affect application behavior. The timeout release describes changes to socket waiting and blocking, and warns about when to set a timeout around connection and TLS operations. If your prototype must recover when a server stops responding, check the behavior of the build you actually install. Do not assume a method with the same name behaves identically across every firmware variant.
There is also the MicroPython download page for the Raspberry Pi Pico 2. On October 10, 2026 it listed v1.29.0, released August 24, as the latest stable release, with preview builds listed separately. That is version information, not evidence that this generic board target supplies every feature a particular WIZnet assembly needs. Pick the documented target for the hardware and application, not the file with the highest version number.
Follow the installation, with the right file
The sequence itself is simple: hold BOOTSEL while connecting USB, wait for the bootloader drive, then copy the matching UF2 file to it. MicroPython's installation instructions describe this process and the automatic reset after programming. Save your project files separately before changing firmware; do not assume an update preserves them.
In our recorded walkthrough, the bootloader drive appeared as RPI-RP2 and the copied file was RPI_PICO-20240602-v1.23.0.uf2. That is an RP2040 Pico example. It is not a record of a Pico 2 or a W5500-specific build being installed, and the filename is not a recommendation for another board. The step that matters is copying the UF2 that matches the board.
Some vendor release assets are ZIP packages. Choose the package for the exact board, read its instructions and identify the firmware file inside before copying anything. We checked the release listings, but have not downloaded or flashed those packages for this note. A ZIP archive is not the UF2 itself.
After the reset, reconnect to the device's serial console. On our PC the board appeared as a USB serial device on COM3. Your computer may assign another number. The 9600-baud value Windows showed in that port's properties is not a setting you need to reproduce for a MicroPython USB console.
Test the function you need before calling the copy finished
Reaching the prompt confirms you can talk to the interpreter. For an Ethernet prototype, the next check is whether the expected network interface initializes using the example for that board and build. Then check address assignment and one small exchange with the intended service. Those are the checks we recommend for the next unit; our installation walkthrough did not cover them.
If a step fails, keep the error and the last successful step. "The USB console opens, but interface initialization fails" gives an engineer a much better starting point than "the replacement board is broken." It also separates a firmware selection problem from wiring, application dependencies or network configuration.
Finally, repeat the small test after disconnecting and restoring power. Keep the result beside the firmware filename and application version. That gives you a usable starting record for another prototype, without implying that one successful exchange shows reliability, security or production readiness.
The aim is modest: make the next board reproducible before making the next batch. A record of the board, its known firmware and the first failing step makes the next engineering task much easier to define.