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:
/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?
I am sure you can find all answers in thedatasheet for the W5100.
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.
See above.
If it is not in datasheet then it is officially not supported even if it works right now for you.
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.
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:
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.
What is the value of TX_FSR? How do you read it? Show the code, and show the pointers.
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.
Can you explain or show how you deactivate CS/RD and CS/WR? Exact timing and their relationship.
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.
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.
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? They are different which is strange for me because W811MJ is based on W5100 right?
If 51 did not get anything, it will not send an ACK. So it may happen that W5100 sends packets, some of them got lost (probably one), then it sends another packet, and PC sees it is out of order and sends dup ACK. Why 3 seconds… no idea. The best test is to have direct connect to exclude the switch.
Can you please point to exact differences? I think if they are material we must raise them to the WIZnet support.
I recall I had issues when deactivating CS and control signals (RD or WR) at different time. After days, or even weeks of struggle I found out that I must deactivate both at the same time.
I would say the information on the pictures is complementary. For me “max 1 ns” actually means “instantly”.
@midnightcow can you please comment? What I see in the WIZ811MJ module is the information I found out empirically several years ago. Why this information is not in the W5100 datasheet?
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.
Your probem is not bus access time.
In the wireshark file, You can see the previious not caputerd packet.
The packet can be sent by SEND command when SOCKET TX buffer is over 2KB.
If SOCKETn TX buffer is over 2KB, W5100 can send to serveral data divided into MSS.
If you send another data by SEND command during the previous serveral data is still sending, you can see the no captured packet.
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.
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:
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:
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:
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 STM32 running on full speed. FMC is not flexiable enough:).
Finally I’ve decided to implement bitbanding for bus direct access. And it looks like it solved the problem! Now I can’t see the issue. Of course now the timings are much bigger then the onces from documentation but I am going to set up the same numbers for FMC and see what happened.
So I am going to check two more things:
set big number timings (just like in bitbandig case) for STM32/FMC and see if still see the issue
use WIZ830MJ (based on W5300) - it looks like setting address just before (or even 8ns max after) /CS assertion is not a problem for W5300 chip which matches STM32/FMC configuration capability
@midnightcow, if you be so kind and provide W5100 bus direct communication timings number, please.
I have checked again to your problem but I still think your problem is not bus access time.
If the bus access time was problem, the sent data is all broken, but your case is not.
If possible, Can you send your source code to my email.
I try to check your FMC time & W5100 driver code.
Thank you.
I have checked your code.
Your code have no problem.
FMC Bus time is ok. It is enough.
but I don’t why the below code is needed
hsram1.Init.WriteFifo = FMC_WRITE_FIFO_ENABLE;
It isn’t needed.
Your problem maybe occurred by another reason.
if your delayed time is 2.8s, it will be expected by your timeout setting (400us , 5 count).
It is calculated as “400ms + 800ms + 1600ms”
Retransmission will be ocurred by no reception of ACK of sent data.
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.
