W5100 datasheet / information issue (1.2.5)

I am writing code which handles interrupts. I am using datasheet version 1.2.5 (latest to date).

  1. Page 8, in /INT section, “All interrupts are maskable. This pin is active low.” is not true. I can not mask interrupt with bits in register Sn_IR.

  2. Sn_INT bit of IR, pages 21-22. Example: “This bit will be automatically cleared when S0_IR is cleared to 0x00.” However on page 27, Sn_IR registers are declared as read-only “Sn_IR (Socket n Interrupt Register) [R] [0x0402, 0x0502, 0x0602, 0x0702] [0x00]”. Same section states “The Socket n Interrupt Register must be cleared by writing ‘1’.” Thus manual contradicts itself: in one place it says to reset interrupt I need to write 0 to register, in another - that I need to write 1 (in bit or in register?). And then it says that this register is read-only.

Please elaborate. Thank you.

Hello,

  1. confirm that all interrupts are maskable and /INT pin is active low.
  2. on page 27, I not found that this register is readonly however…

an extraction from sources that are on the site along with the documentation:

   	/* +200801[bj] interrupt clear */
   	IINCHIP_WRITE(IR, 0xf0); 
      /*---*/   
   	if (int_val & IR_SOCK(0))
   	{
   	/* +-200801[bj] save interrupt value*/
   		I_STATUS[0] |= IINCHIP_READ(Sn_IR(0)); // can be come to over two times.
   		IINCHIP_WRITE(Sn_IR(0), I_STATUS[0]);
      /*---*/
   	}

… the Sn_IR is read and then rewritten safely.

if you need them in the forum there are several implementations in this regard and several resolutions:

[url]W5100 interrupt driven server - #2 by hjjeon0608]
[url]Interrupts don't fire if reading status register - #14 by midnightcow]

Thank you. Please give example of the code, which will cause hardware interrupt when socket 0 has received data (RECV bit of Sn_IR), but does not cause hardware interrupt for sending on socket 0 (SEND_OK bit of Sn_IR).

See attached - circled RED. [R] - means for reading only. Writable registers are marked [R/W].


I require Wiznet to explain its position regarding problems I found in its documentation, and give detailed answers to questions I asked.
At present I see that Wiznet does not have any support capability for its products.

Hi,

we will modify the typing error.
Sn_IR signifies RCW1.
ReadClearWrite1 (RCW1) Software can read as well as clear this bit by writing 1. Writing ‘0’ has no
effect on the bit value.

Please refer to attached file and it is an extract from a W5500 datasheet document.

thanks :slight_smile:
irinkim

Hello, thank you very much.
I attach two screenshots. I am debugging chip operations manually.
I initialized socket in UDP (22h). Then I put DHCP packet into the buffer at 0, and increased TX by 224h bytes. You can see this all on screenshots. Then I give command 21h, and nothing happens. Send LED does not blink, TX register remains 224h, free space register decreases by 224h.
However socket CR register returns to 0 value.

What’s wrong? I would expect W5100 immediately after 21h command send packet, keep write register 224h, keep free size 1000h (I have 4K buffers), and increase read register by 224h. Instead it is stuck with write register 224h, free size 0ddch, and read register 0. No interrupts are generated (mask 03h is set - interrupt sfrom sockets 0 and 1).



Well, after some testing it seems it does what I expect it to do.
Does UDP packet also require header? How can I check what W5100 sends to the wire?

I did another test. I set up fixed configuration for receiving on port 21 (FTP). When I start FTP or telnet on port 21 from remote computer, W5100 flashes LEDs, but receives nothing. NOTHING. Receive pointer is zero.

Another test - initialization in TCP. First 01 - open, then 02 - listen. I perform telnet from remote computer on port 21, and type something. This something gets into the buffer W5100, so I conclude W5100 as device works properly - at least in TCP mode.

What is about UDP mode? How can I test it? Does outgoing packet require header?

Ok, it receives packets in proper format and content. I use ncat to send these packets. However backward direction, from W5100 to listening ncat, still does not work. Ncat says “connect: no error”…

I do not know if this can help but I noticed that you say that put your package starting from the zero position of the TX buffer.
In all the examples I’ve seen the first position of the transmit buffer is read from the registry Sn_TX_WR.
Sn_TX_WR value is the start position for the chip logic when start the transmission not 0.

This register is 0 after connection opening. I can see this data live in the dump, so there is no uncertainty here.

Anyway, I have DHCP working now. Great thanks to Wireshark and Irina Kim. There were several stupid mistakes, starting from wrong MAC address ending with wrong source IP address. I learned that there’re bits of MAC address which should NOT be set for connection working properly at the UDP recipient side.

Eugeny,

Hi I need some help from you please. I see you are further on the path than we are.

We need to interrupt on recieve data from internet to W1500.

When we set up an interrupt on socket 0 we get an interrupt on send data from the micro to the W1500 but not a receive interrupt.

Can you tell me what sequence you have found for read / write to:-

S0_IR
IR
IMR

what do we set up or send to these?

Do we need to access other registers?

Thank you and

Best Regards

Andrew

Hello Andrew, first of all it is important that you initialize all needed registers for proper communication. Just go through register set - main and socket. You may not get receive interrupt simply because W5100 does not receive anything. You do not detail if you see W5100 receiving anything, and which mode you use (TCP or UDP) because required setup in these modes slightly differs.
I can give one small tip: mind SHAR - it can not be anything you want, there’re two bits which indicate specific things, and you should have them preset properly.
Regarding interrupt registers, you should set IMR bit 0 to enable interrupts from socket 0. It is enough for interrupt generation for socket 0, and as you say you get interrupt on sending. This is good. Second what you need to is to perform test while waiting for interrupt check W5100’s socket 0 receive buffer. If it does not receive anything, interrupt will not occur. If it receives something but interrupt does not occur, something is wrong and you need to dive deep into setup and algorithms you use.
But please check setup first. If you use TCP you will need all IP information. If you use UDP, you will need SHAR/ports for broadcasting and other IP information for unicasting. Also for UDP if you do not know remote host’s DHAR, you can populate socket’s IP fields, and W5100 will resolve DHAR using ARP.