---
title: "W5100 FFFF Lockup"
url: "https://maker.wiznet.io/forum/15336"
markdown_url: "https://maker.wiznet.io/forum/15336/md"
type: "Forum topic"
category: "Ethernet Chips"
author: "baysidewilly"
created: "2024-10-26T02:16:42+09:00"
last_activity: "2024-10-26T06:16:42+09:00"
language: "en"
views: 2
replies: 1
source: "WIZnet Makers forum (https://maker.wiznet.io/forum/)"
---

# W5100 FFFF Lockup

## Question

Asked by baysidewilly on 2024-10-26 in Ethernet Chips.

I've unsuccessfully scoured the net, this forum, and the Arduino forums for someone experiencing the same problem so, I'll try posting here.

Equipment: Digilent ArtyS7 with Arduino W5100 Ethernet shield

Environment: ArtyS7 powered with 12V/1.5A supply, JTAG'd via USB. Private network with null cat 5 cable between a laptop and the shield - no other network traffic. The shield communicates with the W5100 via SPI.

Data: ArtyS7 serves a single, static HTML page (450 bytes) via the shield. Page contains a 10s refresh tag.

Setup: Per the W5100 datasheet 5.1 Initialization, all IP/GW/Subnet registers are set as well as Rx/Tx 2K buffers.

Observation: After a random number of page refreshes, S0_TX_WR register is the first to report 0xFFFF. After this occurs, only a power down/up of the shield will return it to operational status.

Details: When working correctly, all page serves display correctly in the browser - no unexpected data/gibberish. TX buffer is written to per the masking algorithm defined in the data sheet. Writes exceeding the 2K buffer boundary are wrapped to the beginning of the buffer address space. The TX buffer read and write pointers match after a SEND is executed. S0_TX_WR register is incremented by the HTML page size before each SEND is executed.

Error: The S0_TX_WR register has been observed to contain 0xFFFF both prior and after an attempted update. This occurrence seems completely random - I have never gotten beyond 150 page refreshes without a failure. Below is a logging snippet from a previous occurrence. Iteration 48 performed correctly, 49 experienced the failure.

48: Socket received RCV, CONNECT irData:0x5
48: main(): readSocket(48)
48: readSocket() rxSz: 0x16B rxRrBaseAddr: 0x0
48: readSocket() gOffSet: 0x0 rxSz: 0x16B
48: readSocket() rxRrBaseAddr: 0x0 += rxSz: 0x16B = 0x16B
48: readSocket() writing RD ptr: 0x16B
48: readSocket(): data:0xF042400 S0_TX_WR0 before S0_CR_RECEIVE txWrPtrAddr:0x8E00
48: readSocket(): data:0xF042500 S0_TX_WR1 before S0_CR_RECEIVE txWrPtrAddr:0x8E9C
48: readSocket(): data:0xF042400 S0_TX_WR0 after S0_CR_RECEIVE txWrPtrAddr:0x8E00
48: readSocket(): data:0xF042500 S0_TX_WR1 after S0_CR_RECEIVE txWrPtrAddr:0x8E9C
48: readSocket() rcvStr: ***GET / HTTP/1.1
Host: 192.168.3.251
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:125.0) Gecko/20100101 Firefox/125.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
Upgrade-Insecure-Requests: 1
Cache-Control: max-age=0

***
48: main(): writeSocket(48)
48: TX socket free size: 0x800
48: pageLoadCnt:48 sendStrSz: 0x1C4
48: txWrPtrAddr: 0x8E9C txRrPtrAddr: 0x8E9C
48: gOffSet: 0x69C + sendStrSz: 0x1C4 = 2144 upperSize: 0x164
48: overflow idx: 355 writing: 0x3A to: 0x47FF
48: wrapping gSO_TX_ADDR: 0x469C gS0_TX_BASE: 0x4000
48: overflow idx: 451 writing: 0x3E to: 0x405F
48: txWrPtrAddr: 0x8E9C += sendStrSz: 0x1C4 = 0x9060
48: writeSocket(): data:0xF0405F3E S0_TX_WR 0x8E9C before txWrPtrAddr 0x9060 update
48: writeSocket(): data:0xF0042490 S0_TX_WR after S0_TX_WR0 update:0x8E9C
48: writeSocket(): data:0xF042500 S0_TX_WR after S0_TX_WR0 update:0x8E9C
48: writeSocket(): data:0xF0042560 S0_TX_WR after S0_TX_WR1 update:0x8E9C
48: writeSocket(): data:0xF042500 S0_TX_WR after S0_TX_WR1 update:0x8E9C
48: txRrPtrAddr after send: 0x9060
48: txWrPtrAddr after send: 0x9060
49: Socket received RCV, CONNECT irData:0x5
49: main(): readSocket(49)
49: readSocket() rxSz: 0x16B rxRrBaseAddr: 0x0
49: readSocket() gOffSet: 0x0 rxSz: 0x16B
49: readSocket() rxRrBaseAddr: 0x0 += rxSz: 0x16B = 0x16B
49: readSocket() writing RD ptr: 0x16B
49: readSocket(): data:0xF042400 S0_TX_WR0 before S0_CR_RECEIVE txWrPtrAddr:0xB800
49: readSocket(): data:0xF042500 S0_TX_WR1 before S0_CR_RECEIVE txWrPtrAddr:0xB8F2
49: readSocket(): data:0xF042400 S0_TX_WR0 after S0_CR_RECEIVE txWrPtrAddr:0xB800
49: readSocket(): data:0xF042500 S0_TX_WR1 after S0_CR_RECEIVE txWrPtrAddr:0xB8F2
49: readSocket() rcvStr: ***GET / HTTP/1.1
Host: 192.168.3.251
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:125.0) Gecko/20100101 Firefox/125.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
Upgrade-Insecure-Requests: 1
Cache-Control: max-age=0

***
49: main(): writeSocket(49)
49: TX socket free size: 0x800

49: pageLoadCnt:49 sendStrSz: 0x1C4
49: txWrPtrAddr: 0xB8F2 txRrPtrAddr: 0xB8F2
49: gOffSet: 0xF2 sendStrSz: 0x1C4
49: underflow idx: 451 writing: 0x3E to: 0x42B5
49: writeSocket(): data:0xF042B53E S0_TX_WR 0xB8F2 before txWrPtrAddr 0xBAB6 update
49: writeSocket(): data:0xF00424BA S0_TX_WR after S0_TX_WR0 update:0xB8F2
49: writeSocket(): data:0xF042500 S0_TX_WR after S0_TX_WR0 update:0xB8F2
49: writeSocket(): data:0xF00425B6 S0_TX_WR after S0_TX_WR1 update:0xFFFF

SPI commands are included in the snippet and have been verified via PulseView. Once the error occurs, no other SPI commands are accepted by the W5100 (including MR reset). During the error condition, I am even able to re-flash the ArtyS7 (with the shield still connected) and restart the webserver code. However, SPI commands are ignored and all registers contain 0xFFFF. Only a true power reset of the shield will correct the problem.

My code follows the W5100 datasheet state machine in 4.2 for the Socket Status Register. I have compared my code to the algorithm from the arduino ethernet library socket.cpp for comparison.

I'm hoping someone else in this forum has seen this problem and can point me in the right direction....

## Replies

### Reply 1 by baysidewilly, 2024-10-26

For the benefit of any humans reading...

1. N/A as this is a shield and no additional reset hardware has been implemented nor is this a power up issue.

2. N/A as the 3.3V supply is provided by the shield. I did monitor its logic value via PulseView during a failure and observed no drop out. However, I could monitor the supply with an O-scope.

3. SPI clock is 10MHz. Minimum as specified (1/period) from SPI Timing pg. 68 is 70ns (approx. 14MHz).

4. N/A as data sheet algorithm has been implemented.

5. SW reset not possible (ignored) once the error has occurred.

6. N/A as only a power cycle corrects the lockup.

Still looking for a human to weigh in with some expertise/experience...

RESOLUTION: Digilent ArtyS7 and Arduino W5100 Ethernet shield were both supplying 3.3V to the power connector. Cutting the 3.3V trace on the shield at the power connector allowed the shield to manage its own 3.3V output from the 5V supplied to the power connector. In later shield layouts, the 3.3V trace at the power connector is missing. I suspect that the ArtyS7 3.3V was randomly interfering with the shield 3.3V, causing the W5100 to partially reset. Once I cut the shield 3.3V trace at the power connector, the ArtyS7 was able to serve up thousands of static HTML pages through the shield without a single error.

---

Source: https://maker.wiznet.io/forum/15336