W5500 multiple spi in one Cpu server

Question

We Have 3 cards 1 . server 1 SET Including Stm32h743iit6 with 2 SEPERATED spi connected to W5500 SPI1,2 Socket 1 Port 5000 Ip :192.168.1.100 Socket 1 Port 5001 Ip :192.168.2.100 ####### 2 .CLIEINT 2 SET client.1 , client.2 EACH ONE HAS STM32F103RCT6 CONNECTED TO SPI w5500 Socket 1Port 5000 Ip 192 168 1 21 Socket 1 Port 5001 Ip 192 168 2 1 When each one of client connected the other one can not connected to the server . For example client 1 connected successful .so now client2 can not connected to the server . I try it to change the board of client 2 to pc by similar ip Port and all of thing . The problem is solved . Without any problem . So i think the program of server is correct What is the problem in client side which change the board to pc the problem would be solved ?

TheoIm · Answer

Hi, the issue you're describing is very likely caused by shared global variables inside the MCU that are being used to manage socket state across multiple W5500 chips. The Core Issue: Shared Socket Variables In the iolibrary/Ethernet/socket.c source file, several static global variables are used to manage the internal state of sockets: static uint16_t sock_io_mode = 0; static uint16_t sock_is_sending = 0; static datasize_t sock_remained_size[_WIZCHIP_SOCK_NUM_] = {0, 0, ...}; static uint8_t sock_pack_info[_WIZCHIP_SOCK_NUM_] = {0, 0, ...}; These variables are indexed by socket number (Sn) and are not chip-aware — they assume that only one WIZnet chip is in use. Why It Fails If both W5500 chips are accessed by the same MCU, and both clients (client.1 and client.2) use socket 0, then both will refer to the same index in these shared variables (e.g., sock_remained_size[0], sock_is_sending & (1 << 0)). This results in state corruption or collision, where the second client cannot properly manage or open its socket because it's unknowingly sharing internal state with the first client. This explains why: Replacing client.2 with a PC (which does not rely on MCU-side shared memory) eliminates the issue. The server code remains unaffected, confirming the root cause is on the client firmware side. Conclusion When two W5500 chips share the same MCU, reusing socket numbers across chips leads to conflicts due to shared internal state in the ioLibrary’s global variables. This prevents the second client from successfully opening or maintaining a socket connection. To avoid this, you must separate socket state tracking per chip — either by modifying the ioLibrary, isolating chip access logic, or enforcing non-overlapping socket numbers with expanded buffer space. Thanks