Can I issue an OPEN command to an already open Socket?

TCP/IP Chip W5500
1

Hi,
I am a beginner with networking messages and I am just learning what I can do with a unit that consists of a PIC32MX795 host cpu and a W5500 network chip.
I have opened a socket to transmit UDP messages and I have noticed that when I issue an OPEN command to this socket the TX_RD register is reset to ‘0’.
This makes life a bit easier as it means that I don’t have to worry about the buffer wrapping around as it would if I “followed the rules” and added my message into the buffer at the offset where the TX_RD register was pointing.
So: my question is - can I issue an OPEN command to a socket that has already been opened ?
Will this have any bad effects on other aspects of the chip’s performance ?

Thanks for any thoughts
PhilipJ

2

You must follow the workflow documented in the datasheet, see W5100 datasheet section 5.2. This is the only guaranteed way for operation. Therefore you must close socket before opening it. And you always must respect TX_RD pointer (and other pointers) and not assume it will always be 0.

3

Hi, thanks for the information. I am using a W5500 and there doesn’t seem to be a similar section in the W5500 datasheet so is it ok to assume these instructions are compatible for this chip?
I wasn’t planning to assume that the TX_RD was ‘0’ I just hoped that I could reset it back to zero after each message send, but I will follow your advice.
Regards
PhilipJ

4

Yes, algorithms described in W5100 datasheet apply. You can’t, and should not reset pointers, they must be operated (read and some of them updated when needed) as described in that section.

5

OK thanks
PhilipJ

6

Hi again, I hope I am not being a pain but I have another oddity happening.
I set up my code as you suggested:
read TX_FSR (this returns 0x0800 as I have 8 sockets)
read TX_RD
write data into the TX_BUF starting at this address
add my message size (in this test case 250 bytes) to TX_RD and write this into TX_WR
issue a SEND command

This is working fine for the first 8 times but when I try to send it a ninth time the problem occurs:
My code is working the buffer pointers as modul0 0x0800 and the data is written into the buffer so that it fills it up to address 0x07FF and then wraps around to write the rest from address 0x0000
The TX_WR pointer becomes 0x00CA.
What actually happens is the W5500 sends 43 messages, each of 1472 bytes and then a 44th message of 442 bytes - total of 63,738 bytes.
It’s almost as if the TX_RD and TX_WR pointers go through the full count of 0 to 65535 and don’t wrap around at 0x07ff.
So my question is:
What is the correct process when the TX_RD pointer is close to the end of the buffer?

regards
PhilipJ
EDIT: I have read the W5500 datasheet about registers TX_RD and TX_WR and it does seem to say (on page 54) that these registers will go all the way to 0xFFFF and then wrap around to 0. So how does this work when the buffer is only 2048 bytes long? How do I know where to put my message data if both TX_RD and TX_WR and pointing at say 0x08ca ?

7

Datasheet says:

/* calculate offset address */
get_offset = Sn_TX_WR & gSn_TX_MASK;
/* calculate start address(physical address) */
get_start_address = gSn_TX_BASE + get_offset;

...

/* increase Sn_TX_WR as length of send_size */
Sn_TX_WR += send_size;
 /* set SEND command */
 Sn_CR = SEND;

You should not touch TX_RD. You must operate TX_WR. TX_WR is a data write pointer for your application. TX_RD is read pointer for W5500 internals. The amount you report also rings the bell - 250 * 8=2000 < 2kB, 250 * 9=2250 > 2 kB, the issue happens at the TX buffer boundary crossing.

That’s why you apply mask to this pointer. Its value is 0…FFFF, but each time it points somewhere within the buffer defined by the configuration (2kB, or 0x800, size in your case).

8

Hi,
but there is no MASK register in the W5500 chip.

HOWEVER, I have worked it out, it seems the W5500 chip has a “virtual” 64k TX buffer (w5599_ds_v109e.pdf page 28) which you can write into BUT only up to the maximum of FREE BYTES (2048 or less_. The block you write is then “mapped” by the chip into the actual 2k bytes of memory allocated for TX messages!!
So all my messing about with modulo 2048 maths was messing up the pointers causing the chip to send 0x10000 - 0x07d0 + 250 bytes in 44 seperate messages.
regards
PhilipJ