W5500 Socket TX Buffer
Ethernet Chips
No replies yet. Be the first to reply.
Join the discussion.
Ethernet Chips
No replies yet. Be the first to reply.
Join the discussion.
Share projects and connect with makers.
Joined before the site update? first.
New to WIZnet Makers?
We sent a verification link to your address. Open it to activate your account, then log in.
Accounts from this email provider are reviewed by an administrator after verification. Approval usually takes one business day.
Already have an account?
Enter your email address. If it belongs to an account, we'll send a link to set a new password. Members who joined before the site update use this to set their password.
If an account uses that address, we sent a link to set a new password. The link works once and expires in 30 minutes.
Know your password?
Need an account?
RE: W5500 Socket TX Buffer
by Eugeny ·
Where’s address pointer masking to stay within the cyclical buffer? See W5100 datasheet chapter 5.2.1.1.
RE: RE: W5500 Socket TX Buffer
by Patrick B ·
This doesn’t work. Maybe for 5100, not 5500. for some reason a wiznet team member forced this post over to the 5100 forum…
W5500 is listed in it’s data sheet as having a cyclical buffer for each socket that ranges from 0x0000 to 0xFFFF.
Plus, there’s no way to force the auto incrementation of the RX_WR or TX_RD register pointer values. These auto increment anytime the Sn_CR is given a RECV or SND command respectively.
I’ve looked at my issue further, and see that the Receive buffer is also an issue. It receives data from the TCP stack but only up until the RX_WR pointer auto-increments to 0x00FF. After that the RX buffer returns junk. RX_WR will continue to increment with ever receive over the TCP stack, but none of the pointer values return meaningful data. I did a full dump of the buffer, reading everything from 0x0000 to 0xFFFF and none of the data appeared to be valid for what was sent to the device over TCP. The only time it worked was when the RX_WR pointer was between 0x0000 and 0x00FF. It then worked again from 0x0800 to 0x08FF, and then every multiple of 0x0800 thereafter. But, I can’t force the RX_WR pointer to jump to that address… I just have to send it 1792 bytes of data to cycle it back around till it’s useful.
Masking doesn’t help with this.
RE: W5500 Socket TX Buffer
by Eugeny ·
Same as W5100. But it is twice larger (16k for W5100/4 sockets and 32k for W5500/8 sockets).
Did not get your point. First you said no auto increment, then say there’s autoincrement. This is how chip works, and it is logical behavior.
In overall it still seems something’s wrong with addressing. Is the first byte in the SPI transaction sent properly? If there’s an issue with it, you’d get similar 0x100 boundary issue.
RE: W5500 Socket TX Buffer
by Patrick B ·
Sorry, I meant that the registers do auto increment, and there is no way to jump to another address, you are forced to transverse the buffer linearly. My point is, that I can’t use masking to force reads or writes to a different area of the buffer, it must be accessed linearly, as read from the pointers listed in the RX_RD/WR and TX_RD/WR registers.
As to the SPI, I am pretty sure that the SPI byte transactions are proper as I am able to set the configuration registers for the chip and the socket, and then accurately receive data sent over the TCP for several transactions.
I suppose it remains possible, however, that there is something incorrect with the addressing used for reading and writing to the socket RX and TX buffers, though I would have expected the boundary issue to present itself differently. Still, at this point I don’t have many other options as to what might be incorrect.
RE: W5500 Socket TX Buffer
by Eugeny ·
Revise figure 20 in the datasheet and ensure you address what you need properly. You not only operate the address, you also operate block select bits. It seems I was not correct pointing you to W5100 and talking about cyclical buffer. W5500 implements it under the hood, and W5100 has it differently forcing programmer doing manual calculations. The remaining socket workflow is similar to W5100. Thus, if you address W5500’s TX buffer of socket 1 (for example) you can use 0-ffff addresses but set bsb to 6. This address 0-ffff will be internally masked to the buffer size and offset to its start in the global socket buffer map.