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?
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?
Ok, agreed, my advises were nonsense and it is good to see you know purposes of those bits.
The first suggestion is to check how hardware reset is performed (circuit, timing?), and perform software reset using MR register. Can you explain how these are done in your setup?
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…
Thanks. I have just realized that it was you having issues with the power supply and PHY being stuck.
Does the current issue happen to the same module? Do you have another module to try?
Have a look at this. While it states about closing the socket, this may well apply to opening the socket. That’s why it would be the best to try another module and see if it works. it if does - this module is an issue, if it does not, we must dig deeper.
If we are going to troubleshoot this module further, can you do two things please:
try using socket 0 instead of socket 1;
dump all the registers from all the sockets. This would be long list, no need in register names, just hex values with addresses, and attach as file (post would be very log). Let’s see the whole picture, who knows what exactly may cause the issue.
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)
Then I would expect at least one socket having its Sn_MR=0x02, and Sn_PORT=0x44. In the dump all the sockets are having nulls. Can you take snapshot just before you set Sn_CR for opening, a second after it happens, and after timeout happens. The timeout formula is listed on the page 39 of the datasheet, and uses 0x7d0 and 0x8. Your chip is having 0xfa0 and 0xa. Not to bother with calculations set them to the value as in datasheet (0x7d0 an 0x08) and wait ~40s … 1m and then make a dump again.
Edit: before you initialization chip has 0x7d0 and 0x08, and I see you modify it. Please do not do it and leave this register as default. And anyway please set first byte of MAC address to 0x2c, at least for the test. And do not change INTLEVEL if it is not critical. And in general leave all the unneeded registers as they are.
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.
and it is good to see you know purposes of those bits.