W5500 cannot open socket in UDP mode for DHCP

Question

Problem statement: When trying to open socket 1 in UDP mode, the socket command register does not reset to zero (keeps the command value) to indicate that the command is being executed and the socket status register stays zero (0). Status: The SPI seems to work fine and the physical also, the link bit (0) in the PHYCFGR register shows in real time when the cable is pluged in or not. Is there perhaps some registers that needs to be setup (or cleared) for a socket to be able to operate in UDP mode for DHCP? My current setup is as follow: General: Mode register (MR): 0x00 Gateway register (GAR): 0x00000000 Subnet Mask register (SUBR): 0x00000000 Source IP (SIPR): 0x00000000 Source HAR (SHAR): 0x2E0745A36137 Interrupt LVL (INTLEVEL): 0x0025 Interrupt Mask (IMR): 0x00 Socket interrupts (SIMR): 0x00 Retry time (RTR): 0x0FA0 → 400ms Retry count (RCR): 0x0A Socket 1: Destination HAR (Sn_DHAR): left unchanged with default: 0xFFFFFFFF Segment size (Sn_MSSR): 0x05B4 (1460) IP type (Sn_TOS): left with default: 0x00 TTL (Sn_TTL): 0x40 (64) RX buffer (Sn_RXBUF_SIZE): 2 → 2k TX buffer (Sn_TXBUF_SIZE): 2 → 2k Interrupt mask (Sn_IMR): 0x00 Fragment (Sn_FRAG): left with default: 0x40000 Keep alive (Sn_KPALVTR): 0x04 → give 20 seconds Socket Mode (Sn_MR): 0x02 Scoket Port (Sn_PORT): 0xC001 Then followed with the open command of 0x01 written to the socket command reg. This is where it gets stucked with value of 0x01. Any suggestions why the socket does not open?

Eugeny · Answer

Use correct MAC address (mind bits 1 and 0 for first octet), and set source IP address and subnet mask. In best case gateway IP address too.

CPC · Answer

The first octet of the MAC address is 0x2E which gives b0 = 0, unicast and b1 = 1, locally administered, which I thought should be the way to go. The ioLibrary has a temporary address with first octet of 0x00, which I also tried with same results. Further, the ioLibrary zero the source IP, Gateway and subnet mask addresses. This socket will be used in UDP for DHCP communication so the Source IP and subnet should be zero but, what should the gateway be set to when it is not know and needs to be discovered too?

CPC · Answer

The module I use is the ETH WIZ click with the W5500 chip. The boot sequence is as follow: 1 - write a logic 0 to the RSTn pin of the W5500 2 - do some other boot requirements which took 1200ms 3 - write a logic 1 to the RSTn pin of the W5500 and wait 600ms before doing anyting else. 4 - do a software reset using the MR register and wait another 400ms just to be sure. 5 - now run through all the register setup, initialization of the common registers and some general socket registers 6 - in the main loop, monitor the link bit (0) in the PHYCFGR register for an active link 7 - when an active link is present, start the DHCP routines (initialize, run) 8 - with a DHCP run the first is to open a socket in UDP mode to send the discover packet This is where the code gets stucked due to the command not being executed. What are the possibillity that a power surge/spike can occurr in the physical part of the chip when opening a socket that may corrupt some registers? A bit far fetch I geuss but, just want to cover all corners…

CPC · Answer

That is right, I set bit 7 and wait until it clears followed by another delay of 400ms.

CPC · Answer

It is the very same module with the current issue. I did not received my spare module yet, so meanwhile I have to troubleshoot this module further. I tried all 8 sockets, all of them with the same results. Attached is the file with the addresses and their values. The first section was dumped before any initialization and the second just after initialization but before socket open function. The socket open function writes 3 registers namely socket mode register (Sn_MR = 0x02) for UDP mode selection, source port reg (Sn_PORT = 68) for client DHCP and destination port reg (Sn_DPORT = 67) for server DHCP. These values read back as they were written. W5500 register dump.pdf (34.7 KB)

CPC · Answer

I found the problem! There was a mixup in register addressing ending up in reading the wrong block in memory (common registers) rather than any of the sockets, my bad, I appologize! At least I know the module is functioning. I can open the socket now and run tha dhcp discover routine and received a 616 byte packet back. I rather close this subject/post and open another if issues with the dhcp routines arises. Thanks for the help.