SPI: VERSIONR=0x28 instead of 0x04

TCP/IP Chip W5500
1

Good time of day,

I’ve got the wiz550io (Ver1.0) and get wrong results when reading VERSIONR, RTR and RCR:

VERSIONR → 0x28 (instead of 0x04)
RTR → 0x1CAB (instead of 0x07D0)
RCR → 0xAB (instead of 0x08)

Since this is my first SPI implementation I’m pretty sure I’m doing something wrong.
Would somebody please take a look at the attached images from the logic analyzer and give me a hint what’s wrong?
(The timings are on the top of the image)

VERSIONR

RTR

RCR

These are the logic analyzer settings:

  • MSB first
  • 8 Bit per Transfer
  • CPOL = 0
  • CPHA = 0
  • EN is active low
2

Dear Zick,

As you know, WIZ550io has embedded mcu for writing or MAC ADDRESS.
This mcu just accesses W5500 after WIZ550io reset.
I wonder that whether your MCU and the embedded mcu in WIZ550io access at the same time or not.

  • Simply, you can test by inserting of wait time (more than 300ms) after WIZ5500io reset.
  • Your MCU can be access on nRDY = ‘0’.

Thanks,

3

Thanks for the suggestion, suhwan!

I think on Ver1.0 of WIZ550io the reset pin is active high. The data sheet 1.0.2 claims this.
So in my case I’m reading VERSIONR when RST ist high.

And getting 0x28 is deterministic. Powering up the board and waiting a few seconds => 0x28. Doing repeated read => 0x28.

Any further ideas?
CPOL and CPHA should be both 0, right?

PS: Looks like this question is WIZ550io specific. Feels free to move it to the appropriate subforum.

4

  1. The first 3 MISO bytes of the reading phase (0x01, 0x02, 0x03) seem plausible. This is an indication that your la settings might be right.

  2. Your MOSI signal rises and falls on a rising clockpulse (CPOL=0, CPHA=1, SPIMODE=1). According to W5500 Datasheet (Version 1.0, page 13) W5500 supports spimode 0 and 3. Apparently SPIMODE=1 is NOT supported.

Explanation of your example VERSIONR:
Because of the unsupported SPIMODE, the w5500 interprets the MOSI different from what is expected.
The 0x39 → 0011 1001 is bit shifted by 1, so the W5500 device actually interprets 0001 1100 → 0x1C.
Your outcome (0x28) makes sense then because that is the default value for PTIMER (register 0x001C).
The bit shift will change the block select bits from 00000 → 10000. This register block is reserved space (Datasheet page 15). It seems that in this case the common register is selected.

SPIMODE definitions: en.wikipedia.org/wiki/Serial_Per … erface_Bus

I get good results here when MOSI rises and falls on a falling clockpulse (CPOL=1, CPHA=1, SPIMODE=3).

5

Thanks a lot, Candela12!
After switching to CPOL=1 and CPHA=1 I get the expected result.
Reading one expected Byte is a real progress after hours of debugging :slight_smile:
Thanks again.

6

Well, I need to correct myself: it works with SPI mode 0 too.
The error I made was improper initialization of the uC hardware. On MSP430 the polarity bit called UCCKPH and is the inverse of CPHA. Found this in the wikipedia article linked by Candela12.