W5100 behaving weirdly

Question

I ported the W5100 driver to the ESP32, as well as a PoC app to test it, and I’m having 2 problems using the chip. But before diving in, I think it’s important to mention that: I’m using the chip in MAC_RAW mode; These problems happen intermittently, and the 1st problem doesn’t seem to occur if I use the chip’s TCP/IP stack (use sockets in TCP/UDP mode). This is important to take into consideration in light of the fact that physical/hardware issues could be to blame. I’m assuming hardware/software as well as physical/logical issues would manifest themselves in a consistent fashion, which is not the case here, adding to the argument against this being something physical/hardware related. I could be wrong in assuming this, though. Let me know if I forgot some other important detail, and I’ll be happy to provide it. The first and foremost issue is the S0_IR_RECV interrupt not triggering at all in any polls, even though Wireshark tells me data has in fact been sent to it. This effectively means data can’t be received through the chip. Here’s the Wireshark capture (1.4 KB) and here’s the Logic 2 capture (870.1 KB). Below is a screenshot of a search for the 0x04 (S0_IR_RECV) value on the MISO line in the capture linked above, in which the only result is a read of the S0_TX_WR register. And here’s a screenshot of part of the Wireshark capture above, showing that data is being received from and sent to the chip (as shown by the DHCPDISCOVER and DHCPOFFER packages). no_recv_ws1071×515 209 KB There is a second variant of this issue in which data is said to be sent by the chip, in which S0_IR_SEND_OK is asserted, but Wireshark shows that nothing has crossed the wire. And here’s the capture (1.6 KB) followed by an img of it no_send942×638 265 KB And here’s a log of a run of the PoC app mentioned above showing the path of execution of the test firmware, as well as hexdumps of everything passing through the link layer. Both variants of this first issue are identical with regards to the produced log. The second issue is a weird behavior that happens sometimes during initialization, in which the S0_CR_CLOSE command actually doesn’t get executed by the socket at all, and initialization gets stuck in the close() loop routine. Here’s the Logic 2 capture (873.2 KB) and below is the gist of what I’m talking about sock_close_issue1800×234 18.8 KB The way I get around this problem is by not calling the socket close function before socket initialization, and go straight to opening the socket in MAC_RAW mode. Since it can be avoided, this is more of a low priority issue, but is still a problem. Here’s a dump of a few registers when the close command fails. To make it easier to follow, the registers being read are MR, IR, IMR, RTR and RCR (I was just curious to see if there was anything relevant in both of them), S0_MR, S0_IR, S0_SR reg_dump_sock_close1920×1080 60.8 KB Any help is much appreciated.

dev07 · Answer

Apparently I was wrong regarding the 2nd problem when I said that I could skip closing the socket. It turns out that it doesn’t help. lol1859×309 23.4 KB Logic 2 capture (305.0 KB)

dev07 · Answer

Solved /RESET wasn’t being properly pulled.