---
title: "W5500 Version Number"
url: "https://maker.wiznet.io/forum/16009"
markdown_url: "https://maker.wiznet.io/forum/16009/md"
type: "Forum topic"
category: "MCU & Boards"
author: "jhinkle"
created: "2026-03-21T09:44:44+09:00"
last_activity: "2026-03-23T10:04:50+09:00"
language: "en"
tags: ["W5500"]
views: 4
replies: 1
source: "WIZnet Makers forum (https://maker.wiznet.io/forum/)"
---

# W5500 Version Number

## Question

Asked by jhinkle on 2026-03-21 in MCU & Boards.

I have purchased several W5500io (what they call a tsp/ip ethernet module - both the small and long versions).

I''''m concerned that the boards might be build using reject W5500 chips because none of the every return a Version of 4 per the W5500 spec. The boards appear to work otherwise - at least thru DHCP acquiring an IP address - still testing the rest.

The current small io board returns a version number of 0x5d.

The long ones return all kind of different version numbers.

I was using the version number in my start-up thread to validate that the W5500 was working properly but have abandoned that test since none of the chips return a 0x04.

Are these defective chips that have been marketed as good W5500 modules?

Any comments appreciated.

Why have a forum when an AI is replying and not addressing the issue - then telling to to use a different site. Why publish anything on the forum is no reply can be expected?

Better fix your W5500 AI responses because the Version register is 0x39 - not 0x49 as stated in the AI response.

## Replies

### Reply 1 by Lihan__, 2026-03-23

Hello,

First of all, we sincerely apologize for the confusion caused by our AI bot's inaccurate response. We also appreciate you taking the time to identify and report the version register address error. The correct address for the W5500 version register is **0x39**, and your observation is absolutely correct.

The issue of **0x5D** being returned from that address is more likely due to a communication configuration problem rather than a defective chip. Please refer to the possible causes below.

---

**1. SPI Signal Integrity** Noise on the SPI line can cause register values to be read incorrectly. Please keep the wiring as short as possible, and as an initial diagnostic step, try lowering the SPI clock to **5MHz or below** to see if the issue persists.

---

**2. Missing Initial Reset** The W5500 requires a Reset after power-on to stabilize its internal register states. Could you confirm that this initialization sequence is being performed correctly?

- **HW Reset**: Hold the `RSTn` pin **LOW for at least 500µs** → return HIGH → wait **at least 1ms** before starting communication

- **SW Reset**: Set **bit7(RST) of the Mode Register(**`**0x0000**`**) to 1** (it automatically returns to 0 upon completion of initialization)

---

**3. SPI Frame Format** Please review whether the SPI frame structure specified in the datasheet (Address Phase, Control Phase, etc.) is being followed correctly. The W5500 SPI frame consists of the following 3 phases:

```plaintext
[Address Phase: 16bit] [Control Phase: 8bit] [Data Phase: Nbyte]
```

The correct frame for reading the version register (`0x0039`) is as follows:

```plaintext
0x00, 0x39, 0x00 → 1byte read
```

The Control Byte must be **0x00**, based on `BSB[4:0]=00000` (Common Register Block), `RWB=0` (Read), and `OM[1:0]=00`. If this value is set incorrectly, an unintended block will be read, which can result in an incorrect value such as `0x5D` being returned.

---

For a more accurate diagnosis, please capture the SPI waveform using a **logic analyzer** and share the image with us — this will allow us to provide a more precise analysis.

We hope to resolve this issue as quickly as possible. Please don't hesitate to reach out if you have any further questions.

Thank you.

---

Source: https://maker.wiznet.io/forum/16009