How to Configure Common Registers with WIZnet W5500 on MCU Platforms?
This maker-focused W5500 register article explains how an MCU configures the WIZnet W5500 through its common register block
How to Configure Common Registers with WIZnet W5500 on MCU Platforms?
Summary
This maker-focused W5500 register article explains how an MCU configures the WIZnet W5500 through its common register block. It covers mode control, gateway, subnet, MAC address, local IP, interrupt handling, retry timing, unreachable-port diagnostics, PHY link status, and chip-version checking. W5500’s role is to provide the Ethernet MAC/PHY, hardwired TCP/IP engine, socket system, and register-addressed network control while the MCU performs SPI register access and application logic.
What the Project Does
The source article is a register-level walkthrough, not a full application such as HTTP, FTP, or MQTT. It focuses on the W5500 common register block, where the MCU configures device-wide Ethernet behavior before using socket registers. The article starts with MR at offset 0x0000, then explains network identity registers such as GAR, SUBR, SHAR, and SIPR, followed by interrupt, retry, PPPoE, unreachable-address, PHY, and version registers.
The architecture is register-driven. The MCU sends W5500 SPI frames that select the common register block, provide a register offset, choose read or write access, and transfer data. For example, the gateway address is stored in GAR0–GAR3, the subnet mask in SUBR0–SUBR3, the MAC address in SHAR0–SHAR5, and the local IPv4 address in SIPR0–SIPR3.
For makers, this is the layer that explains why higher-level examples work. Before TCP, UDP, DNS, SNTP, FTP, or MQTT can run, W5500 must know its local MAC address, IP address, gateway, subnet mask, interrupt mask, retransmission behavior, and PHY link state. The article’s register map therefore acts as a bridge between board bring-up and socket programming.
Where WIZnet Fits
The exact WIZnet product is W5500. W5500 is the wired Ethernet controller between an external MCU and the LAN. It integrates a 10/100 Ethernet MAC and PHY, supports hardwired TCP/IP protocols including TCP, UDP, ICMP, IPv4, ARP, IGMP, and PPPoE, provides 8 independent sockets, and includes 32 KB internal Tx/Rx buffer memory. It connects to the MCU over SPI up to 80 MHz.
In this register-level architecture, the MCU does not own the full TCP/IP stack. Instead, it writes common registers for global network identity and behavior, then uses socket registers and buffers for communication. W5500 owns the hardware network engine, while the MCU owns SPI access, initialization order, retry policy, interrupt service flow, and application protocol logic.
The common register block is important because it controls system-wide behavior. MR can trigger software reset, Wake-on-LAN, ping block, PPPoE mode, and force-ARP behavior. IR, _IMR_, SIR, and SIMR define device and socket interrupt handling. _RTR_ and _RCR_ define retransmission timeout and retry count. UIPR and UPORTR record unreachable IP and port diagnostics. PHYCFGR reports and configures link, speed, duplex, and PHY mode.
Implementation Notes
File: Ethernet/W5500/w5500.h in WIZnet ioLibrary
What it configures: SPI access direction and W5500 memory block selection.
Why it matters: Every register access depends on the control byte. The MCU must distinguish read vs write and select the common register block, socket register block, TX buffer block, or RX buffer block before the address offset has meaning.
#define _W5500_SPI_READ_ (0x00 << 2)
#define _W5500_SPI_WRITE_ (0x01 << 2)
#define WIZCHIP_CREG_BLOCK 0x00
#define WIZCHIP_SREG_BLOCK(N) (1 + 4 * N)
#define WIZCHIP_TXBUF_BLOCK(N) (2 + 4 * N)
#define WIZCHIP_RXBUF_BLOCK(N) (3 + 4 * N)The CSDN article explains the same model: W5500 frame access uses the common register block selector for global registers, and the official ioLibrary defines the block macros used by W5500 register access code.
File: Ethernet/W5500/w5500.h in WIZnet ioLibrary
What it configures: common register addresses for local network setup, interrupts, retry behavior, diagnostics, PHY status, and chip identification.
Why it matters: These definitions are the base layer used before socket code. If GAR, SUBR, SHAR, or SIPR are wrong, higher-level TCP/UDP applications may fail even when SPI access appears normal.
#define MR (_W5500_IO_BASE_ + (0x0000 << 8) + (WIZCHIP_CREG_BLOCK << 3))
#define GAR (_W5500_IO_BASE_ + (0x0001 << 8) + (WIZCHIP_CREG_BLOCK << 3))
#define SUBR (_W5500_IO_BASE_ + (0x0005 << 8) + (WIZCHIP_CREG_BLOCK << 3))
#define SHAR (_W5500_IO_BASE_ + (0x0009 << 8) + (WIZCHIP_CREG_BLOCK << 3))
#define SIPR (_W5500_IO_BASE_ + (0x000F << 8) + (WIZCHIP_CREG_BLOCK << 3))
#define PHYCFGR (_W5500_IO_BASE_ + (0x002E << 8) + (WIZCHIP_CREG_BLOCK << 3))
#define VERSIONR (_W5500_IO_BASE_ + (0x0039 << 8) + (WIZCHIP_CREG_BLOCK << 3))The official ioLibrary groups these as common registers for basic network configuration, interrupt control, retransmission, PPPoE, ICMP diagnostics, PHY configuration, and version checking. The source article walks through the same common-register purpose from a learning perspective.
Practical Tips / Pitfalls
- Read
VERSIONRearly. The official ioLibrary notes thatVERSIONRshould indicate the W5500 version value, so it is a simple SPI and chip-select sanity check before debugging networking. - Configure
GAR,SUBR,SHAR, andSIPRbefore opening sockets. These registers define the gateway, subnet, MAC address, and local IP used by later TCP/UDP communication. - Treat
IRandSIRdifferently.IRreports global conditions such as IP conflict and destination unreachable, whileSIRsummarizes which socket has an interrupt pending. - Clear interrupt bits deliberately. The article explains that interrupt status remains asserted until the host clears the relevant register bits.
- Tune
_RTR_and_RCR_for the application. The article gives the default-style example0x07D0 = 2000, which equals 200 ms because the unit is 100 µs; retry count then affects when timeout interrupts appear. - Use
PHYCFGRduring bring-up. Its link, speed, and duplex bits distinguish a firmware problem from a physical Ethernet problem.
FAQ
Q: Why use WIZnet W5500 for a register-level maker project?
A: W5500 exposes a clear hardware-socket model. Makers can learn how gateway, subnet, MAC, IP, interrupt, retry, PHY, and version registers map directly to Ethernet behavior, while still using a controller that includes a hardwired TCP/IP stack, 8 sockets, and internal packet buffers.
Q: How does W5500 connect to the MCU platform?
A: W5500 connects through SPI. The MCU sends W5500 frames containing an address phase, control phase, and data phase; the control field selects the register or buffer block and the read/write direction. In a practical board, reset and interrupt pins should also be connected so firmware can recover the chip and handle events without constant polling.
Q: What role does W5500 play in this register article?
A: W5500 is the network engine being configured. The article focuses on its common register block: mode control, local network identity, interrupt status and masks, retry timing, unreachable-address reporting, PHY configuration, and chip-version confirmation.
Q: Can beginners follow this maker project?
A: Yes, if they already understand basic SPI, hexadecimal register offsets, IPv4 addressing, and MCU GPIO control. It is lower-level than an HTTP or TCP demo, but it is a good bridge from “the module works” to “I know which register controls the network behavior.”
Q: How does W5500 compare with an LwIP-based approach?
A: With W5500, the MCU talks to a hardware TCP/IP controller through registers, sockets, and internal buffers. With LwIP, the MCU runs a software TCP/IP stack; LwIP is a small independent TCP/IP implementation designed to reduce RAM usage while still providing a full-scale TCP stack for embedded systems. W5500 is better for learning hardware offload and SPI register control, while LwIP is better for studying software stack internals, packet buffers, timers, and network-interface integration.
Source
Original article: CSDN, “W5500通用寄存器介绍,” published on 2025-08-05 and marked as CC 4.0 BY-SA.
WIZnet product reference: W5500 documentation.
WIZnet driver reference: Wiznet/ioLibrary_Driver, MIT license.
LwIP reference: lwIP 2.1.0 overview.
Tags
#W5500 #WIZnet #Registers #CommonRegisters #SPI #MCU #Maker #Ethernet #TCPIP #PHYCFGR #ioLibrary #LwIP #NetworkStack
