Incorrect reading Sn_SR againe

TCP/IP Chip W5500
1

Hello, first of all I saw 3 topic about Sn_SR reading problem but didn’t see the solution. I have the same problem Sn_SR is always 0. In the same time all communications is working.
I use STM Discovery board and HAL library to communicate via SPI using DMA. Baud Rate 1,5Mbits/s.
Trying solve the problem I make an experiment in witch I read (one after one without any other reading of writing via SPI):

  1. 4 registers starting from MR for socket 1 and receive 13 (Sock_init) at position number 4;
  2. 3 registers starting from CR for socket 1 and receive 13 (Sock_init) at position number 3;
    In this 2 experiments at MISO line I saw 1,2,3 for fist 3 byte (address and command).
  3. 2 registers starting from IR for socket 1 and receive 0 at position number 2;
  4. 1 registers starting from SR for socket 1 and receive 0 at position number 0;
    And at MISO I saw 1, 0, 8 and 1,2,6 for first 3 byte for 1st and 2nd message.
  5. 4 registers starting from MR for socket 1 and receive 13 (Sock_init) at position number 4;
  6. 3 registers starting from CR for socket 1 and receive 13 (Sock_init) at position number 3.
    In this 2 experiments at MISO line I saw 1,2,3 for fist 3 byte (address and command) also.
    So, as I understand if all is OK at MISO for first 3 byte will be 1,2,3 is it true? I have oscillograms of communication process if it is interesting I can post it.
    And the second question could I read IR and SR register without reading CR register? And why it happens? As I understand it must be possible to read it.
2

Yes, the 0x1,0x2,0x3 bit is true, this can be seen in my analyser pics in the lost interrupt thread too.

3

Hello,

I’m currently working on a project using a STM32f4 and a module based on W5500 (the most common one on amazon, with a yellow connector).

Sorry to bump this old topic, but it seems that I’m experimenting the exact same issue than alenic: reading or writing to some specific address fail. This occurs for instance for the socket status register (addr = 0x3 in socket block), but also with GAR1 (addr = 0x2 in common block).

I can read the value of GAR0 (100% success with 100000 tries), but I fail to read GAR1 (99.8% failure with 100000 tries). My SPI receive function checks for the 0x1, 0x2, 0x3, and fails if one of the received byte is wrong.

This is what I receive when it works (GAR0):

tx 0x00 0x01 0x00 0x00
rx 0x01 0x02 0x03 0xc0

This is what I receive when it works (GAR1):

tx 0x00 0x02 0x00 0x00
rx 0x01 0x00 0x06 0x01
(2nd, 3rd and 4th rx bytes are wrong)

So, it seems the failure occurs before the control phase (3rd tx byte) is received, so it does not depend on register block, read/write access, or SPI operation mode.

It looks that SPI phase and polarity is correct, but I tried the 4 combination to be sure. I also decreased the speed by a factor 8 (I’m below 1 Mhz). Unfortunatly, I have no logic analyzer to capture the signals, which would probably help.

Like [alenic], I can workaround the problem when accessing to the socket status register by doing an access to 3 bytes starting at the socket control register, but this won’t help when I’ll be accessing Tx/Rx buffers.

Any idea would be really welcome !
Thanks

4

Hello, try to reduce clk, miso, mosi lines. It’s help me to solve the problem.

5

Hi Alenic,

Thank you for your answer. You mean the length of the cable, not the frequency, right ? Currently I’m using 20cm “dupont” cables for prototyping. Do you think there can be bounces on the lines?.. especially knowing I decreased the SPI frequency to 200Khz!

(EDIT: I did a test by changing GPIO speeds in STM configuration, I had the impression that it changed something, but after several tests, it is not reproducible at all…)

I’ll try to change the cables, but I don’t have a lot of hardware, so it won’t be that easy :confused:

Anyway thanks again, and if anyone has another idea, I’m still interested!

6

Yes, I mean length. May be the problem was in contact quality, I am not sure. I have some cables with different length. I just replaced the cables to shorter and it solved my problem.