W5100S Socket-less ARP function

TCP/IP Chip W5100S
1

Dear all.

I’m looking for clues as to what may be breaking the routine described in 4.7 of the manual.
Following the example, when my development receives a network discovery/broadcast, it then
uses the sequence to determine the MAC address of the peer device that issued the discovery packet.

All works well, reading the peer hardware/MAC address from SLHAR registers.

Problem occurs when another peer issues a discovery and the same routine is followed.
WireShark shows that the ARP packet being broadcast to the peer and the peer responding correctly.
The routine for the command to complete, then completes, as before

   do{								 // Till command is completed
      State = _WIZ_Get08(0x004C);		// SLCR (Socket-less Command Register)
									//
   }while(State);

then

   for(;;){							// Till Done
      State = _WIZ_Get08(0x005F);		// SLIR (Socket-less Interrupt P38)
      if(bit_test(State, 1))break;			// Reply received
      if(bit_test(State, 2)){				// Time Out
         WIZ_PIN_CS = 1;				// Chip UnSelect
         IND_FireAI();					// WireSharkless test 3
         return FALSE;					//
         								//
      }//End If						//
									//
   }//End loop						//

Here, the problem occurs, in that the data I read from

_WIZ_Get(HWAdr, 0x0054, 6);   		// SLPHAR (Peer MAC from ARP)

is now stale data from the first time that the routine was run…
The result being, that data for the second peer is sent to the correct IP address ant the wrong MAC address.

Resetting the chip clears the problem but obviously, highly inefficient…
Ideas on a post card…

2

Datasheet says:

Each Command must not be executed at the same time and not configured before SLCR cleared.

I suspect it is what you are looking for - you must respond to previous ARP before next ARP arrives, otherwise new ARP request overwrites previous one. Did I understand your problem correctly?

But for me it sounds ridiculous.

3

I see that documented under section 3.1.31, however, I may not have explained that in this case, I’m not responding to ARP requests, I am sending them and then reading the result from SLPHAR. The first operation always works as expected, and subsequent operation solicits the correct network request and response. After the first response, the SLPHAR register is no longer updated, and will always contain the data from the first occasion that the SLCR[ARP] is called.

I’m not too sure what you mean by

How do I respond to an ARP when I generated it and received the response?
May be, there something else that should be done to complete the process before issuing another ARP command?
Subsequent ARP commands and responses are not overwriting the first one in SLPHAR.

4

So, after much experimentation, I’ve learned that I’m not able to clear SLIR[ARP]
This is causing the next ARP call to complete when SLCR == 0, but SLIR[APR] == 2.
Put in a long delay and SLPHAR does update with the correct response.

I guest the question now, is, how do I force SLIR clear, any one? 3.1.39 indicates [RW]

5

OK, now I understand the counter intuitive nature of the SLIR.
In order to clear an interrupt bit, it must be set… :astonished:
My suggestion for the next revision of the manual is this.

{
START :
/* set SOCKET-less Retransmission Time, 100ms(0x03E8) (The unit is 100us) */
SLRTR[0:1] = {0x03, 0xE8};
/* set SOCKET-less Retransmission Counter, 5 */
SLRCR = 0x05;
/* set Interrupt Mask Bit */
SLIMR[ARP] = ‘1’; // ARP Interrupt Mask Bit
/* clear all Interrupt Bits by setting */
SLIR = 0x07; // ARP Interrupt Register Bits
SLIMR[TIMEOUT] = ‘1’; // TIMEOUT Interrupt Mask Bit
/* set Destination IP Address, 192.168.0.100 */
SLPIPR[0:3] = {0xC0, 0xA8, 0x00, 0x64};
}

This now works for me.

1 Like