WIZ811MJ (W5100) Bus mode communication few questions

Question

Hi, I am wondering which signal is used at W5100 to latch address from the bus. Is it failling edge of /CS or maybe falling edge of /WR for write operation (/RD in case read operation)? Is it ok that address is changing at the same time /CS is asserted or maybe a few nanoseconds delay between setting address and /CS failling edge is must? I am wondering whether bulk write/read operation is supported by W5100? I’ve tried to enable bulk write as on the picture below: IMG_20181120_1900113956×2976 1.91 MB /CS asserted at the beginning of the bulk and kept low till bulk finishes. /WR toogling to write subsequent bytes in the W5100 memory. Is that flow is ok or maybe /CS should be toogled as well just like /WR?

Eugeny · Answer

I am sure you can find all answers in thedatasheet for the W5100. zbigelpl: Is it failling edge of /CS or maybe falling edge of /WR for write operation (/RD in case read operation)? Pages 65-66, “Register/Memory READ Timing” and “Register/Memory WRITE Timing”. You must comply to them, and you will get reliable result. Pics clearly show that address must be earlier than CS, and all other signals can be same or later than CS. zbigelpl: or maybe a few nanoseconds delay between setting address and /CS failling edge is must? See above. zbigelpl: I am wondering whether bulk write/read operation is supported by W5100? If it is not in datasheet then it is officially not supported even if it works right now for you. zbigelpl: Is that flow is ok or maybe /CS should be toogled as well just like /WR? Is it ok for you? Do you have proper read? Why you want bulk read for parallel access? It makes a sense for serial SPI communication, for parallel access it does not add much value.

zbigelpl · Answer

Thanks for your response. I am aware of timing parameters from datasheet. But I was wondering if 8ns (minimum) between address setting and CS failing edge matters for W5100. And wondering at which edge (CS or WR) address is latched in W5100. I observe odd W5100 behavior and looking for the root cause. It is about that from time to time W5100 stops sending TCP segments for ~2,8seconds. Please see how it looks like on whireshark logs: w5100-communication-gap1273×501 29.4 KB In regular case W5100 sends TCP segment every 11ms. Sometimes it stops sending more segments - frame 13479 is the last one before the gap, and frame 13494 is the first one after the gap. After the gap W5100 tries to send TCP segment with Seq missing four TCP segment (1460 bytes each). While the gap, when W5100 doesn’t send any segment, TX_FSR register says there is no room in the TX buffer. W5100 configuraion: TX buffer size = 8kB RTR = 4000 RCR = 5 So it could be a result of no enough delay between address set and CS failing edge? Or maybe bulk write could cause the issue? Regarding the bulk write, it looks like it works. I use embedded memory controller (FMC from STM32) to communicate with W5100. And using bulk write (no toggling on CS line) could copy data to W5100 memory much faster. And in case ~1500bytes per single copy it makes differences.

zbigelpl · Answer

Eugeny: What is the value of TX_FSR? How do you read it? Show the code, and show the pointers. Code reading this is taken from W5100 official site. Here you are the function reading TX_FSR value: /** @brief get socket TX free buf size This gives free buffer size of transmit buffer. This is the data size that user can transmit. User shuold check this value first and control the size of transmitting data */ uint16 getSn_TX_FSR(SOCKET s) { uint16 val=0,val1=0; do { val1 = IINCHIP_READ(Sn_TX_FSR0(s)); val1 = (val1 << 8) + IINCHIP_READ(Sn_TX_FSR0(s) + 1); if (val1 != 0) { val = IINCHIP_READ(Sn_TX_FSR0(s)); val = (val << 8) + IINCHIP_READ(Sn_TX_FSR0(s) + 1); } } while (val != val1); return val; } IINCHIP_READ() is implemented just as reading data from address since so far I used FMC (Flexible Memory Controller) and treat WIZ811 (W5100) as external static memory. Eugeny: But for me it looks like packet has been lost. Draw the topology of the connection (with devices in between of W5100 and receiver, and tell at which node Wireshark log is being gathered. Connection between WIZ811 and PC goes trough TP-LINK swtich. I’ve tested with both cable from router (with the Internet) connected and disconnected. Testes told me that it doesn’t matter. I didn’t checked it with direct connection between WIZ811 and PC so far - will do it. Wireshar is running on the PC. Regarding lost packets - I thought that if packet was lost, packet retransmittion is done. RTR = 4000, RCR = 5 so I guess if WIZ811 didn’t get ACK it should retransmit data packet within 400ms but it waits ~2800ms to take any action. And the action is sending next packet in a raw. Eugeny: Can you explain or show how you deactivate CS/RD and CS/WR? Exact timing and their relationship. Will do soon. I decided to put aside FMC for now and generate all address, data and strobe signals on it own, I mean by driving GPIOs. I will set correct timings. BTW, which timings are correct? This one from W811MJ or W5100 documentation?…

zbigelpl · Answer

Eugeny: Can you please point to exact differences? I think if they are material we must raise them to the WIZnet support. W5100 specification: https://www.wiznet.io/wp-content/uploads/wiznethome/Chip/W5100/Document/W5100_Datasheet_v1.2.7.pdf WIZ811MJ specification: http://wiznethome.cafe24.com/wp-content/uploads/wiznethome/Network%20Module/WIZ8XXMJ/Document/WIZ811MJ_DS_V120E.pdf image788×1340 181 KB So: t3/3 (/CS low to /RD low) and t4/4(/RD high to /CS high) - W5100 doc says min=0, max=???, WIZ811MJ doc says min=???, max=1ns. t5/5 (/RD high to Valid Data Output) - W5100 doc says min=48ns, max???, WIZ811MJ doc says min=???, max=80ns Similar inconsistencies are about timings for WRITE as well.

zbigelpl · Answer

Hi again guys. I had a pretty long break in work on my wiz811mj based project. But now it is time to get back to this. So reassuming. My problem is about TCP based communication gaps happend. Gaps are always ~2.8seconds long (with my curreny w5100 settings) but happend in totally random moments - there is no rule about this. I suspected that the problem could be reading/writing many W5100 registers while single /CS assertion. But just like midnightcow said: midnightcow: W5100 can support the burst mode. That is, It is possible that you can read/write while /CS is always low and /RD or /WR is toggled every data. But, It need a delay 32ns while /RD or /WR is toggled. And it makes sense because in my case I used burst mode all the time while writing/reading W5100 TX/RX memory but issue happends randomly. The second suspicion was about timings in communication between STM32 and WIZ811MJ. I found out that WIZ811MJ and W5100 documention show different timings. Eugeny said the timing from these two documents could be complementary - it makes sens. But I would like to be sure which numbers exaclty I should follow while setting up bus direct communication. Midnightcow said: midnightcow: Your probem is not bus access time. But I would like to be sure I set up bus direct communication with the right way. @midnightcow are you able to help me with that and provide the right timing’s numbers? Then I’ve followed the: midnightcow: If you think the no caputerd packet is problem, You wait until data is completely sent before you send another data. Or, You do not use the SOCKET TX buffer over 2KB. I’ve tried both: combine my single packet (1460bytes) into one long packet 4*1460bytes and send it and wait TX buffer is completly empty set TX buffer to 2KB and still saw the issue. So I still suspecting the problem is about the timings, especially there is not way to set the 8ns long “Valid Address to /CS low time” for STM32 peripherial device - FMC (Flexible Memory Controller) when…

zbigelpl · Answer

I’ve send you project I’ve prepared for testing wiz811 and track down the 2.8s gap issue. Thanks a lot

zbigelpl · Answer

packets_before_and_after_the_gap.zip (63.7 KB) At the attachement I send you wireshark logs. There are tcp frames captured for the transmission between wiznet and PC. The most interesting moment is between frame no. 1782 and 1783. There is the gap. Between wiznet and PC there is a router. All happened in home LAN. There is really small traffic. Regarding FMC_WRITE_FIFO_ENABLE, I agree. It is not needed. I’ve checked with FIFO_DISABLED and issue still happened. So this settings doesn’t matter in context the gap issue. Thanks a lot.