Wiznet makers

🔎 Context

A developer using a Texas Instruments TMS320F28379D (C2000 series) LaunchPad tried to communicate with WIZ810Sio, and seeking help from the TI community due to below issues.

• SPI configuration mismatch
• Hardware reset sequence
• Timing issues
• Or compatibility limitations of TI’s SPI peripheral with the WIZnet module.

This post is valuable because it highlights integration challenges when pairing industrial TI MCUs with WIZnet Ethernet controllers.

🧪 What the User Tried

The developer reported:

✅ They properly wired SPI:

• MOSI
• MISO
• SCK
• CS
• RESET pin

✅ SPI settings used:

• 20 MHz clock
• CPOL = 0
• CPHA = 0 (Mode 0)
• 8-bit transfers

❌ But behavior was incorrect:

• Reading the W5100S Version Register always returned 0x00.
• All other register reads also returned zeros or invalid data.
• No SPI error flags were triggered on the TI MCU side.

They also verified:

• Power supply is stable
• Reset behavior on the W5100S
• Multiple SPI speeds
• Multiple CS pin configurations
• Examined signals on an oscilloscope

Nothing resolved the lack of response.

🗣 TI Expert Feedback

TI engineers replied with several key insights:

1️⃣ Check SPI mode compatibility

TI noted that although Mode 0 is typical, W5100S has strict timing requirements.
They recommended testing Mode 3 (CPOL=1, CPHA=1) as some peripherals behave differently depending on internal sampling edges.

2️⃣ Verify the chip-select (CS) timing

TI explained that C2000 SPI hardware requires CS to remain asserted during the entire SPI frame and that some pins or GPIO handling patterns may de-assert CS prematurely.

If CS flickers or rises between bytes, the W5100S will ignore data.

3️⃣ Lower the SPI frequency for debugging

TI recommended starting at 1 MHz or even lower because:

• The W5100S has a deterministic internal clock requirement
• Some C2000 boards have longer trace lengths on boosterpacks/daughtercards
• High frequency may cause marginal timing failures

4️⃣ Confirm the RESET sequencing for W5100S

TI engineers asked the user to verify:

• RESET low time meets minimum spec
• Delay before first SPI access is sufficient

WIZnet chips require a full internal boot period after reset, and premature SPI access may read zeros.

5️⃣ Suggested logic analyzer or Saleae capture

To compare the actual waveform with what the W5100S expects (timing, gaps, chip-select behavior, data framing).

⚠️ Thread Outcome

As of the last update:

• The user had not successfully communicated with the W5100S module yet.
• They were continuing to experiment with SPI modes, frequencies, and reset sequencing as suggested.
• TI did not find a definitive hardware incompatibility — instead, they pointed to timing and mode configuration as the likely cause.

This thread remains unresolved but provides valuable diagnostic guidance for anyone pairing high-performance TI MCUs with WIZnet Ethernet modules.

📌 Key Technical Takeaways for Makers

🔹 1. WIZnet SPI chips are extremely sensitive to CS timing
Some MCUs release CS between bytes unless carefully controlled.
WIZnet chips require continuous CS across multi-byte transactions.

🔹 2. RESET timing matters
WIZnet devices need a full internal boot period after reset (tens of milliseconds).

🔹 3. Always test multiple SPI modes (0 and 3)
Some MCU implementations have subtle sampling-edge differences.

🔹 4. Start slow — 500 kHz to 1 MHz
W5100S and W5500 will work reliably at low speed; scale upward later.

🔹 5. Check wiring, power, and ground integrity
Even minor grounding issues can cause consistent misreads (0x00).