Boron 404x and Adafruit ethernet

Connectivity
1

Hello, I'm troubleshooting a strange behaviour using Boron 404x with adafruit ethernet featherwing

I'm trying to test the Adafruit Ethernet featherwing on a Boron 404x on a simple socket connection to one device on the same LAN. However, while I see ARP traffic, I can't get any useful connection traffic from the Boron. I have soldered the nRESET to D3, and nIRQ to D4 (I also did CS on D5 after some initial failures). Using wireshark I can see the Boron initiating ARP requests where it looks for a gateway if I use a config like this:

Ethernet.setConfig(NetworkInterfaceConfig()
.source(NetworkInterfaceConfigSource::STATIC, AF_INET)
.address({192,168,1,21}, {255,255,255,0})
.gateway(SockAddr({192,168,1,254})));

I'm following the example code here and tried on 5.5.0, 5.6.0, and 6.1.0:

I think this means the hardware is configured correctly. Additionally, I can see it run an ARP request for a LAN destination (ie. 192.168.1.64) if I use TCPClient to attempt an IP based HTTP connection to 192.168.1.64:80, but not a TCP SYN. The target even responds to the ARP request correctly, but the Boron doesn't attempt to open a socket it just continues sending the same ARP request for the destination IP over and over, like it's unable to take the next step.

With STATIC IP and a gateway the boron doesn't seem to be able to reach the cloud either, because, again, it's stuck repeatedly trying to ARP the gateway. I've tried with and without DNS, and with variations on the structure passed (IPAddress, SockAddr, or just {}), also tried with and without AF_INET included in the config.

If I either try with a switch and DHCP, or with an isolated LAN using .gateway(SockAddr({0,0,0,0})), then the Boron makes an initial DHCP request, but it's in a "Ethernet not Ready" state, which I think is supposed to be OK for the Isolated LAN option because it has no gateway??? I'd prefer Static IP anyway. This still doesn't allow the Boron to avoid getting stuck on ARPing.

It appears to have functioning ethernet communication, and is requesting MAC info in reaction to the TCP/IP request, why could it be ignoring the response or failing to process the response and establish the MAC connection? Does anyone have a basic ethernet connection working with a Boron 404x and adafruit to share? Thanks!

2

I was able to get a Boron to use a static IP address with the Adafruit Ethernet FeatherWing. I think the reason it's not working for you is that you don't have DNS specified, and it's required because that's how the cloud server is found. I could not connect without DNS, but it worked once I added it.

This is the setup using the Adafruit Ethernet FeatherWing and the default pins:

Particle Pin Ethernet FeatherWing Pin
MISO SPI MISO
MOSI SPI MOSI
SCK SPI SCK
D3 nRESET
D4 nINTERRUPT
D5 nCHIP SELECT

IMG_4736
IMG_47361600×1200 281 KB

This is the firmware I used. Tested with Device OS 5.6.0.

#include "Particle.h"

SYSTEM_MODE(SEMI_AUTOMATIC);
SYSTEM_THREAD(ENABLED);

SerialLogHandler logHandler(LOG_LEVEL_TRACE);

// setup() runs once, when the device is first turned on
void setup() {
    // Comment out the following line in production; used only to see all serial debug messages
    waitFor(Serial.isConnected, 10000); delay(1000);

    System.enableFeature(FEATURE_ETHERNET_DETECTION);

    Cellular.off();
    Ethernet.on();

    
    Ethernet.setConfig(NetworkInterfaceConfig()
        .source(NetworkInterfaceConfigSource::STATIC, AF_INET)
        .address({192, 168, 2, 26}, {255, 255, 255, 0})
        .dns(SockAddr({8, 8, 8, 8}))
        .gateway(SockAddr({192, 168, 2, 1})));
  
    // To restore DHCP:
    // Ethernet.setConfig(NetworkInterfaceConfig().source(NetworkInterfaceConfigSource::DHCP, AF_INET));
 

    Ethernet.connect();
    
    waitFor(Ethernet.ready, 10000);
    Particle.connect();
}

void loop() {
}
1 Like
3

Thanks Rick, I tried your code exactly on 5.6.0 with only the IP address changed to 192.168.1.99 to comply with my LAN along with the gateway to 192.168.1.254 (confirmed from other LAN devices). I received the following output and still see the continuous ARP traffic:

0000251203 [system] WARN: Internet test failed: -230 network
0000251203 [system] WARN: Handling cloud error: 2
0000263204 [system] INFO: Cloud: connecting
0000263208 [system] WARN: Failed to load session data from persistent storage
0000267201 [system] ERROR: Failed to determine server address
0000267202 [system] WARN: Cloud socket connection failed: -230
0000271201 [system.cm] ERROR: No addrinfo for e0......a.v6.udp-mesh.particle.io#5684
0000271203 [system] WARN: Internet test failed: -230 network
0000271203 [system] WARN: Handling cloud error: 2
0000283204 [system] INFO: Cloud: connecting
0000283208 [system] WARN: Failed to load session data from persistent storage
0000287201 [system] ERROR: Failed to determine server address
0000287202 [system] WARN: Cloud socket connection failed: -230

This repeats and the LED cycles from fast cyan, to slow green, to a brief yellow/red that I don't recognze, and then back to fast cyan.

I had been testing previously with a 3rd party SIM, and so I subsequently ran a test with the credentials reset to internal sim and removed the external, but that also had no effect and I still see the output pasted above.
Cellular.setActiveSim(INTERNAL_SIM);
Cellular.clearCredentials();

That output looks to me like it confirms the DNS failure, but I don't actually see any ethernet traffic attempting the DNS request, it still seems trapped in ARP requests and I'm wondering if the Boron is confused about which interface it's supposed to be communicating with. I wonder if I've somehow introduced a persistent setting in previous my tests that's working against me now? (ie. MANUAL mode, 3rd party SIM, etc) I'll try with a fresh Boron later, but any guidance in the meantime?

***Edit: Is there any possibility of a difference in operation between the Boron LTE in your photo, Rick, and the 404x version? Everything else looks identical

4

I used device doctor to refresh the firmware, then flashed the code provided. Here is a longer log output including the initial cloud handshake log, with the device id edited out:

0000005252 [system] INFO: Cloud: connecting
0000005257 [system] INFO: Cloud socket connected
0000005257 [comm.protocol.handshake] INFO: Establish secure connection
0000005261 [comm.dtls] INFO: session has 0 uses
0000005277 [comm.dtls] INFO: (CMPL,RENEG,NO_SESS,ERR) restoreStatus=0
0000005279 [comm.dtls] INFO: out_ctr 0,1,0,0,0,0,0,13, next_coap_id=a
0000005279 [comm.dtls] INFO: restored session from persisted session data. next_msg_id=10
0000005281 [comm.dtls] INFO: session cmd (CLS,DIS,MOV,LOD,SAV): 2
0000009110 [net.pppncp] TRACE: NCP event 3
0000009111 [net.pppncp] TRACE: NCP power state changed: IF_POWER_STATE_DOWN
0000009111 [system.nm] TRACE: Interface 4 power state changed: DOWN
0000009112 [ncp.client] TRACE: Modem powered off
0000009112 [ncp.client] TRACE: Deinit modem serial.
0000009113 [comm.dtls] INFO: session cmd (CLS,DIS,MOV,LOD,SAV): 4
0000009115 [comm.dtls] INFO: session cmd (CLS,DIS,MOV,LOD,SAV): 3
0000009115 [comm.protocol.handshake] INFO: Sending HELLO message
0000009117 [comm.coap] TRACE: Sending CoAP message
0000009117 [comm.coap] TRACE: CON POST /h size=39 token= id=11
0000013851 [comm.coap] TRACE: Retransmitting CoAP message; ID: 11; attempt 1 of 3
0000013851 [comm.coap] TRACE: Sending CoAP message
0000013852 [comm.coap] TRACE: CON POST /h size=39 token= id=11
0000024382 [comm.coap] TRACE: Retransmitting CoAP message; ID: 11; attempt 2 of 3
0000024382 [comm.coap] TRACE: Sending CoAP message
0000024384 [comm.coap] TRACE: CON POST /h size=39 token= id=11
0000042350 [comm.coap] TRACE: Retransmitting CoAP message; ID: 11; attempt 3 of 3
0000042351 [comm.coap] TRACE: Sending CoAP message
0000042352 [comm.coap] TRACE: CON POST /h size=39 token= id=11
0000075225 [comm.coap] ERROR: CoAP message timeout; ID: 11
0000075226 [comm.dtls] INFO: session cmd (CLS,DIS,MOV,LOD,SAV): 0
0000075226 [comm.dtls] INFO: session cmd (CLS,DIS,MOV,LOD,SAV): 4
0000075230 [comm.protocol.handshake] ERROR: Could not send HELLO message: 10
0000078238 [system.cm] ERROR: No addrinfo for e...a.v5.udp-mesh.particle.io#5684
0000078240 [system] WARN: Internet test failed: -230 network
0000078240 [system] WARN: Cloud handshake failed, code=-160
0000078492 [system] INFO: Cloud: disconnecting
0000078492 [system] INFO: Cloud: disconnected
0000078492 [system] INFO: Cloud: connecting
0000078496 [system] WARN: Failed to load session data from persistent storage
0000082238 [system] ERROR: Failed to determine server address
0000082240 [system] WARN: Cloud socket connection failed: -230
0000086238 [system.cm] ERROR: No addrinfo for e...a.v5.udp-mesh.particle.io#5684
0000086240 [system] WARN: Internet test failed: -230 network
0000086240 [system] WARN: Handling cloud error: 2
0000086341 [system] INFO: Cloud: connecting
0000086344 [system] WARN: Failed to load session data from persistent storage
0000090237 [system] ERROR: Failed to determine server address
0000090237 [system] WARN: Cloud socket connection failed: -230

It repeats continuously after that.

5

No addrinfo for e...a.v5.udp-mesh.particle.io#5684

That indicates an issue with DNS, either the setting is not working, or your network is blocking access to the DNS server.

In my example I used a public DNS (8.8.8.8) but you may need to use a local DNS, which may or may not be the same address as your gateway.

6

I understand, but if this was caused by a failure in the DNS request, or a bad address I'd at least see the DNS request over TCP to the gateway, right? I never see any IP traffic at all from the ethernet board, only constantly repeating and ignored ARP requests. So I think it's a deeper root cause. Here is a link to someone else experiencing the same issue with W5500:

Can I somehow override the mac address setting on the W5500 through the Ethernet library to test the solution here where a different mac address got the ARP requests working? Without a functioning MAC/Ethernet layer I don't think any DNS/IP troubleshooting can progress, right?

Edit: For completeness, I tested changing the DNS to the gateway's listed DNS servers. This didn't fix the issue.

7

Good point, I agree that the W5500 is not communicating at all, and that's why the DNS is failing, not because of a DNS problem per se.

The W5500 does not have a built-in MAC address from the factory and it's set by the Particle device. It uses a locally administered MAC address, which may be significant if the LAN prohibits them.

It's a formula based on the unique ID masked into the nRF52 processor (FICR), and some other bits, this is the code. So different Boron devices will have different MAC addresses, even with the same W5500.

8

We finally traced this down to a problem with the featherwing implementation on the prototype PCB, some pins weren't connected across in accordance with the standard the way we thought they were. So while the D3 and D4 pins were jumpered on the Ethernet side they weren't getting correctly connected across from the Boron. After changing to an Adafruit featherwing to match your implementation the problem was apparent. Thanks for the help, the first set of code is working exactly as expected once the hardware is fixed!

3 Likes
9

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