W5500 not working on SPI1?

So the chip and wires are almost working (green light on, orange does not),
But I must be missing something if Ethernet.begin(...) doesn't work..

Starting w/ libs, installed NCD_Ethernet_Overlay via Workbench,
And activated with #include <Ethernet.h> (and in turn "w5500.h", <EthernetClient.h>, etc.)

Here's the serial output; curiously, it doesn't return the manually set IP addr after Ethernet.begin(), and on 2nd pass it returns nothing -

0000009299 [app] INFO: Trying Eth.begin
0000010300 [app] INFO: Spec IP addr is:
0000010300 [app] INFO: Eth IP addr is:
0000010301 [app] INFO: Could not cnx to serv
0000012305 [app] INFO: Trying Eth.begin
0000013306 [app] INFO: Spec IP addr is:
0000013306 [app] INFO: Eth IP addr is:

And code -

#include <Ethernet.h>

unsigned long lastLogT = 0;                              
unsigned long tcpRead = 3000;                           // 3s
bool cnxT = false;

SerialLogHandler logHandler(115200, LOG_LEVEL_INFO);
EthernetClient eClient;                                 // Global instance
byte mac[] = { 0xde, 0xad, 0xbe, 0xef, 0xfe, 0xed };
IPAddress locIP(192,168,0,150);                            
IPAddress servIP(192,168,0,39);
int servPort = 1701;

void setup() {
    lastLogT = millis();

    if (!cnxT) {
        Log.info("Trying Eth.begin");
        Ethernet.begin(mac, locIP, locIP, locIP);   // Repeat IP for Gateway, DNS
        Log.info("Defined IP is: %s", locIP.toString().c_str());
        Log.info("Actual IP is: %s", Ethernet.localIP().toString().c_str());

void loop() {
    if (millis() - lastLogT >= tcpRead) {
        lastLogT = millis();

        if (!eClient.connected()) {
            if (eClient.connect(servIP, servPort, 1)){
                Log.info("Connected to serv");
            } else {
                Log.info("Could not cnx to serv");
        } else {

            if (eClient.available() > 0) {
                while (eClient.available() > 0){
                    Log.info((const char*)eClient.read());

I should add telnet to same server IP works great, from a 'similar' ( PC with same settings (same IP addr for its Gateway, DNS as well).

Actually reports localIP = as corrected above

Wonder if the SPI1 bus takes a moment on reboot (due to JTAG switchover) and Ethernet.begin() is running before SPI1 is ready?
But with that loop throttle I doubt it's the issue here...

I also gather that the pinMode of SS pin (D5 on SPI1) is called via setup() > Ethernet.begin() > w5500.init() > initSS() ...
Such that Ethernet.begin() has to be called in Particle setup();

And digitalWrite() on SS pin is happening in setSS() and resetSS() of w5500.cpp,
But so far I haven't heard a packet out of the w5500..

It may help to know if/when to call lines like -
And any others?

SPI.begin(pin) or SPI1,begin(pin) set the pinMode of the CS/SS pin. Though since you can have multiple SPI devices on a single bus, you can also set the pinMode manually.

FEATURE_ETHERNET_DETECTION is not available on the Electron. It should only be enabled on the Boron if you are using the built-in support for Ethernet, which can only be used on SPI, not SPI1.

You mean in loop()?

Copy that, thanks.

Note the helpful w5500 forum seems to think my SPI1 is wonky...
Here's what I'm chasing, coz the code seems good no? (Hopefully screenshots help show it)

EthernetClass Ethernet.begin(), with w5500.init()
[in Ethernet.cpp]

Also w5500_cspin = D5
[in Ethernet.h]

And for example w5500.init() showing where I sub'd D5 and changed it to SPI1... (including .beginTransaction)
[in w5500.cpp]

Finally swapped out D5 in pin toggles
[in w5500.h]

For this, if software calls above are correct (default from lib), why is MISO low level when chip is deselected?

MISO is indeterminate when there is so SPI device selected.

The SPI master (the Particle device) is input, which is always high impedance. There is no default pull on SPI, unlike I2C.

The SPI slave devices should be in high impedance when not selected (CS high), and only drive it push-pull when selected.

1 Like

Thanks for that, and trying to understand, is the CS trace above backwards?

If so, then does the lib above have it backwards?
(To confirm, high impedance = output level hi and low = output lo?)

Noting again I sub'd D5 for A2 (since SPI1), and I did retype pinMode(D5, OUTPUT) in setup()
(to be sure it got set on boot-up)

And while we're talking hi/lo, the int and reset pins should be OUTPUT High in setup(), no?
Technically OUTPUT_OPEN_DRAIN for int, but yea it's the only chip on SPI1 so figure both the same.

Actually not sure what you mean here?
Like make MISO an INPUT_PULLUP, beyond the SPI1 lib assignment?

No, you can't override the pin, its handled automatically. The trace you posted looks normal, though it's impossible to say for sure without the whole thing decoded.

EDIT - My zoomed out trace, which I take as wrong - no?

  • Coz it (just above) shows MISO idles Low until slave transmits, but then SparkFun below does the same. (Note, I don’t have pullups or pulldowns on the MISO or MOSI)
  • Else CS looks funky / similar, where it does a Low jog (on left side) before the frames start (on right side) - is this the JTAG changeover on boot?
  • Perhaps most importantly, my CS cycles High / Low each frame (per initSS() and resetSS() funcs in w5500 lib), whereas SparkFun does not - is this correct?

For reference, this SparkFun trace -

MISO should be low when no CS line is selected. Technically it's floating, but the logic analyzer will report this as low.

The pin state changes don't really match the JTAG pin states. It looks like SCK is going high, but pin D4 isn't used by JTAG. Assuming SS/CS is D5, that's pulled high when in JTAG mode while the boot loader is running and yours is going low.

Yes, the pin SS/CS pin should change state when the init/reset SS calls are made. How often this is will vary depending on the library.

Keep in mind you're using a 3rd-party library which may have bugs. And even in the unlikely event there is a problem with SPI1 on Device OS 2.x on the Electron, it won't be fixed. That device is deprecated and Device OS 2.x is in ESM (extended support) phase and a new version would only be created for a security issue, not for a bug fix. All development has ceased on 2.x and 3.x release lines.

Thanks for all your notes Rickkas7

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.