W5500 LinkLED/AcktLED behaviour


#1

Hi.

So I’m trying to implement W5500 in a custom PCB and I can’t seem to get it to work.

When I plug in the Ethernet Cable the LED’s blink consequentially (quickly), in an approximate 2 second interval. So for example:
This happens fast:
LED1 turns ON.
LED1 turns OFF.
LED2 turns ON.
LED2 turns OFF.
[approx 2 second both LED OFF]
[repeat]

The lenght of time the LED’s are ON is NOT consistent. Most of the time the LED’s switch very quickly, but sometimes one of them takes somewhat longer.

What does this sequence mean? I’m writing a custom driver for the W5500 and I can’t seem to get it to work, but I’m wondering if the problem is in my custom PHY PCB layout (I followed the reference designs) or in my W5500 initialization routine.

I have a W5500io board and when I plug the same Ethernet cable, the behaviour is more like expected (one LED consistently ON, the other blinks occasionally) so I’m guessing the problem is not on the router end.

I’d be extremely grateful for any help, or even simply an explanation of what the LED sequence means.


#2

hi,
you can find the description of the LEDs on page 10 of the datasheet.
You’re going to check the status of the network through the state of the LEDs?
If so maybe you should read the correct register: PHYCFGR (W5500 PHY Configuration Register) [R/W] [0x002E] [0b10111XXX]
(page 43 of datasheet) that has DPX bit for duplex status, SPD bit for the speed status and LNK bit for the link status and do not blink :wink: and if you have a free i/o can turn on your own LED as you please.


#3

Hi. Thanks for the help. :slight_smile:

The thing is, I don’t really think that the LED’s are the problem as much as they’re probably the symptom of a larger issue with which I hoped someone here would be familiar with.
After the initialization the contents of the PHYCFGR are 0b10111010 which seems to indicate HalfDuplex, 100 Mbps and Link down.

I’m guessing this means that the W5500 tries to establish a link but doesn’t seem to be able too? I’m guessing that the period where the LED’s are ON is the period where the W5500 tries to establish the link.

Would that be a correct assesment?

I’m really pulling my hair here. It feels like I’m missing something really crucial in the initialization procedure but I can’t figure out exactly what. If there’s a problem with the PCB layout, then I’m seriously screwed.

This is the raw init routine code. Am I doing anything exceedingly stupid?

The parameters for w5500_SendCommand are (in order):

  • Address
  • Socket (or common)
  • R/W
  • Data from which to read or where to write
  • Number of bytes to r/w

[code] // Reset W5500
one_data[0] = 0x80;
w5500_SendCommand(MODE, CMN, WRITE, one_data, 1);

// WoL disabled, disable ping block, disable PPPoE
// Force ARP disabled
one_data[0] = 0x00;
w5500_SendCommand(MODE, CMN, WRITE, one_data, 1);

// 1. Set Default Gateway address
w5500_SendCommand(GATEWAY_ADDR, CMN, WRITE, def_gateway, 4);

// 2. Set Subnet Mask
w5500_SendCommand(SUBNET_MASK, CMN, WRITE, subnet_mask, 4);

// 3. Set Source IP (set on router using MAC)
w5500_SendCommand(IP_ADDR, CMN, WRITE, ip_addr, 4);

// 4. Set Source MAC Address
w5500_SendCommand(MAC_ADDR, CMN, WRITE, mac_addr, 6);

// 5. Set Retry Count to 170
one_data[0] = 0xAA;
w5500_SendCommand(RETRY_COUNT_REG, CMN, WRITE, one_data, 1);

// 6. Set Socket S0 Mode - Enable Multicasting, UDP mode
one_data[0] = 0x80;
w5500_SendCommand(MODE, S0, WRITE, one_data, 1);

// 7. Set source port number of S0
one_data[0] = 0x00;
one_data[1] = 0x1A;
w5500_SendCommand(SOCK_SR_PORT, S0, WRITE, one_data, 2);

// 8. Set Destination Mac Address SOCK_DEST_MAC
w5500_SendCommand(SOCK_DEST_MAC, S0, WRITE, mac_addr_dest, 6);

// 9. Set Destination IP Address SOCK_DEST_IP
w5500_SendCommand(SOCK_DEST_IP, S0, WRITE, ip_addr_dest, 4);

// 10. Set Destination Port Address
one_data[0] = 0x00;
one_data[1] = 0x1A;
w5500_SendCommand(SOCK_DEST_PORT, S0, WRITE, one_data, 2);

// 11. Initialize RX/TX Buffer Sizes
one_data[0] = 0x02;
w5500_SendCommand(RX_BUF_SIZE, S0, WRITE, one_data, 1);
w5500_SendCommand(TX_BUF_SIZE, S0, WRITE, one_data, 1);

// 12. Set TimToLive parameter
one_data[0] = 0x40;
w5500_SendCommand(TTL, S0, WRITE, one_data, 1);[/code]

#4

Hi,
from what I remember once you’ve set the main parameters (IP,MAC,GW and SUBNET) and buffers the device responds to the ping without having to do anything else ( your PHYCFGR is taken from PMODE[2:0] PINs = All capable, Auto-negotiation enabled ).
My init sequence in any use I make it is always the same: 4 parameters and buffers, when using DHCP set all the parameters to 0 except for the MAC address and then set them with the data info returned from the server.
Your initialization sequence seems correct … only I set the buffer immediately after essential common parameters like gateway, MAC, subnet and IP and before using any socket register but there should be no problems :unamused: .
Are you sure you read the registers properly? You tried to read for example the word at 0x0039 (VERSIONR) that should be 0x55 0x00?


Link LED starts flashing when ethernet cable connected, but no network activity
#5

Hi!

It works!

Thank you for your help. The problem turned out not to be in the initialization routine, but in the physical layout. I’ve desoldered a couple of resistors which were there experimentally, and the damn thing came alive. Definitely taught me not to eyeball damping resistors. :smiley:

Again, thank you for your willingness to step up. :slight_smile:


#6

Hi Salieri, I’m having the same symptoms. Would you mind elaborating on what your problem was? Were the “experimental” resistors damping resistors in series with the TX and/or RX lines? Or pull-up/pull-down resistors? Did you end up using any of these in your working design?


#7

Hi!

Yeah, I was talking about the series resistors in line with Rx/Tx. I took them out and short-circuited the connection, and it worked. I wound up throwing them out of the final design since I had the W5500 fairly close to the jack so there wasn’t much added inductance or capacitance to dampen.
I kept the pull ups as per the reference design.


#8

Great - I’ll try that. Looking back, the reference schematic I used actually defies these as 0R, but in the EMI reduction text panel suggest experimenting with non-0R values. I put in 33R as per their experiments, but in hindsight I should have started with 0R and worked up…

Thanks!


#9

I do not use resistors on TX / RX and I have such a problem.
323
If you turn it off and on several times, it starts working well.


#10

W5500 can not catch carrier properly, and resets its PHY in loop.

Share your circuit diagram and board layout.

This behavior can be caused by another device you connect another end of the cable to (e.g. switch/hub). Try another hub to see if there will be any difference.


#11

I use different builds and get the same effect. This does not always happen, and only when power is applied.


PMODE2, PMODE1, PMODE0 all Pull-up.