w5500 not working on SPI1?

Question

Hi, striving to get the w5500 working on Particle Electron using NCD_Ethernet_Overlay.h/.cpp; The lib supports Particle and the code seems to jive … So I dove into SPI bus after verifying the obvious (pinMode / SS assignment, setSS(), resetSS() in EthernetClient.cpp, etc.), and here’s an example trace I got; Are these Voltage swings unstable or should we expect a little slew / bounce? EDIT - should now be full cycle. And then is this about right for a SPI exchange? Coz I’m getting nothing out of the RJ45 (Wireshark) despite verifying a PC can connect to the TCP server (@ 192.168.0.39), unlike this post which seemed to at least get something. name type start_time duration mosi miso CAN can_error 3.07339159 1.00E-05 SPI enable 3.07345541 4.00E-09 SPI result 3.07345682 1.00E-06 0x00 0x00 SPI result 3.07345922 1.00E-06 0x00 0xFA SPI result 3.07346158 1.00E-06 0x00 0xFA SPI result 3.07346395 1.00E-06 0x00 0x05 SPI disable 3.07346668 4.00E-09 SPI enable 3.07349923 4.00E-09 SPI result 3.07350062 1.00E-06 0x00 0x00 SPI result 3.07350302 1.00E-06 0x00 0xFA SPI result 3.07350538 1.00E-06 0x04 0xFA SPI result 3.07350775 1.00E-06 0x85 0x05 SPI disable 3.07351047 4.00E-09 SPI enable 3.07354303 4.00E-09 SPI result 3.07354441 1.00E-06 0x00 0x00 SPI result 3.07354681 1.00E-06 0x1E 0xFA SPI result 3.07354918 1.00E-06 0x0C 0xFA SPI result 3.07355155 1.00E-06 0x02 0x05 SPI disable 3.07355426 4.00E-09 SPI enable 3.07358683 4.00E-09 SPI result 3.07358821 1.00E-06 0x00 0x00 SPI result 3.07359061 1.00E-06 0x1F 0xFA SPI result 3.07359298 1.00E-06 0x0C 0xFA SPI result 3.07359534 1.00E-06 0x02 0x05 SPI disable 3.07359806 4.00E-09 SPI enable 3.07363069 4.00E-09 SPI result 3.07363208 1.00E-06 0x00 0x00 SPI result 3.07363448 1.00E-06 0x1E 0xFA SPI result 3.07364028 1.00E-06 0x2C 0xFA SPI result 3.07364274 1.00E-06 0x02 0x05 SPI disable 3.07364546 4.00E-09 SPI enable 3.07367809 4.00E-09 SPI result 3.07367947 1.00E-06 0x00 0x00 SPI result 3.07368187 1.00E-06 0x1F 0xFA SPI result 3.07368424 1.00E-06 0x2C 0xFA SPI result 3.0736866 1.00E-06 0x02 0x05 SPI disable 3.07368932 4.00E-09 SPI enable 3.07372195 4.00E-09 SPI result 3.07372334 1.00E-06 0x00 0x00 SPI result 3.07372574 1.00E-06 0x1E 0xFA SPI result 3.0737281 1.00E-06 0x4C 0xFA SPI result 3.07373047 1.00E-06 0x02 0x05 SPI disable 3.07373318 4.00E-09 SPI enable 3.07376575 4.00E-09 SPI result 3.07376713 1.00E-06 0x00 0x00 SPI result 3.07376953 1.00E-06 0x1F 0xFA SPI result 3.0737719 1.00E-06 0x4C 0xFA SPI result 3.07377427 1.00E-06 0x02 0x05 SPI disable 3.07377698 4.00E-09 SPI enable 3.07380961 4.00E-09 SPI result 3.073811 1.00E-06 0x00 0x00 SPI result 3.0738134 1.00E-06 0x1E 0xFA SPI result 3.07381576 1.00E-06 0x6C 0xFA SPI result 3.07381813 1.00E-06 0x02 0x05 SPI disable 3.07382085 4.00E-09 SPI enable 3.07385341 4.00E-09 SPI result 3.07385479 1.00E-06 0x00 0x00 SPI result 3.07385719 1.00E-06 0x1F 0xFA SPI result 3.07385956 1.00E-06 0x6C 0xFA SPI result 3.07386193 1.00E-06 0x02 0x05 SPI disable 3.07386464 4.00E-09 SPI enable…

Eugeny · Answer

Why SPI “1”? When W5500 accepts the byte, it puts 0x01, 0x02, and 0x03 onto the MISO. You have 0x00, 0xfa, 0xfa therefore something is broken in your SPI communication. As long as you have such scope/logic analyzer, show at least one full access cycle with all four signals. Homework for you to deconstruct what you see in there and prove MOSI is correct (or find the issue and fix it).

Eugeny · Answer

emcdee: and I’ve updated what I believe is a full access cycle, above Where? I expect 4 separate time-aligned signal logging.

emcdee · Answer

Apologies, you mean the enable and clock signals aren’t shown in data table, beyond miso and mosi? Else lemme try to show trace output in a better video preview -

emcdee · Answer

And here’s the SPI1 setup funcs -

Eugeny · Answer

emcdee: better video preview I do not need video preview. I need one read/write cycle in picture which timing and waveform I can analyze.

emcdee · Answer

Ah ok let’s try, Overview (channel IDs) - image808×494 16.7 KB First two frames - image1669×502 19.1 KB Close up of 1st frame - image1248×501 22.6 KB Close up of 2nd frame - image1413×507 22.8 KB I’m not sure why the 1st frame is ‘blank’ from MOSI (despite getting a MISO), tho SPI in Mode-0 if that helps… and SPI1 is dedicated to to just this w5500. Thanks for your patience / support

Eugeny · Answer

MISO can’t be low level when chip is deselected. What W5500 module do you use, and what is connection circuit of everything into SPI bus?

emcdee · Answer

Appreciate that insight, Using the w5500 >> 48-LQFP (7x7) eth_sck = SCLK eth_SI = MOSI eth_SO = MISO cs (pin D5) = SCS eth_int (output high else pull-up) = INT eth_reset (output high else pull-down) = RST pull-down on EXRES1 Pull-up / down here just means in hardware setup, but those overrode by pinMode as output high. Else in code the CS pin in code per w5500 lib - [w5500.cpp] And - [w5500.h]

Eugeny · Answer

emcdee: Pull-up / down here just means in hardware setup, but those overrode by pinMode as output high. I am almost convinced this is your problem. Value being read for MR - 0x05 - may be correct one if reserved bits read as 1. So you have problem with MISO in the first, second, and third sections (bytes) of the transaction.

emcdee · Answer

Eugeny: MISO can’t be low level when chip is deselected. Oh, now I can set those (int, reset) to stay at a value (override pull-up/down resistors), and I had them as OUTPUT High to avoid interfering w/ bus -

Eugeny · Answer

emcdee: Oh, now I can set those (int, reset) to stay at a value (override pull-up/down resistors), and I had them as OUTPUT High to avoid interfering w/ bus - Not sure I understand what you are doing. Interrupt pin must be tristate at the controller side, and reset pin must be driven actively depending on the need. You must stop driving MISO line at the controller side. Pull-ups are there to ensure it is in weak 1 when not driven by the SPI slave device.

emcdee · Answer

OK thanks for that, Actually there are only pull-up on int and pull-down on reset; not on MISO, MOSI (tho I read some folks prefer it on these as well). So I output high on reset (while running normally), and leave int and MOSI, MISO alone. Let me know if that’s not correct (figured spi1.begin, etc. in w5500 libs controls the CS pin, so long pins are specified correctly).

emcdee · Answer

Eugeny: You must stop driving MISO line at the controller side In fact what does it mean to put w5500 chip in slave mode? Coz I’m not touching the int pin, or should I be?

Eugeny · Answer

INT is not a part of the SPI specification. Your board must have MISO pulled up with let’s say 10k resistor, All other pins are actively driven by the MCU, but you may have pull-ups (all except CLK) or downs (CLK) if you wish. INT may be pulled up with 10k resistor, and is an input to the MCU. It may be driven actively by the peripheral (W5500); pull-up is required in case peripheral output is open-collector or tri-state. During SPI communication MCU drives CLK, CS, MOSI, and reads MISO. Means first three are in output mode at the MCU side, and fourth in input mode at the MCU side.

emcdee · Answer

Thank you very much for this.

Eugeny · Answer

Sorry made mistake in INT passage, corrected, please take a look.

emcdee · Answer

Ok for now (bear with me), if we pretend it’s fine as produced with no pull-ups/downs on MISO or MOSI (perhaps w5500 doesn’t care?), and ignore my boot-up frames (on left side of my trace, per MCU docs) → Does it matter that my CS cycles High / Low each frame whereas SparkFun’s CS stays Low 'til done? Focus on the right side of my trace (updated here) - SparkFun example (upside down, noting they call PICO = MOSI and POCI = MISO) - image708×575 116 KB

Eugeny · Answer

emcdee: → Does it matter that my CS cycles High / Low each frame whereas SparkFun’s CS stays Low 'til done? Not sure I get what you ask for. Look into the datasheet section 2, you will see everything you need regarding SPI access. emcdee: if we pretend it’s fine as produced with no pull-ups/downs on MISO or MOSI (perhaps w5500 doesn’t care?), Main point was you stop driving MISO by MCU (its acronym name stands for Master In Slave Out). It is an output of SPI slave device, and input to the MCU. It is recommended to have pull-up, but will work without it. Next design ensure pull-up is in there.