Argon 0.8.0-rc-25 Issues

I have a fair amount of Photon devices running and was going to try it out on the newly arrived Argon with a dev board setup on the same hardware platform. I ran into two immediate issues…

After rewriting entire networking sections… I noticed that both const IPAddress ip(1,2,3,4) and locally scoped IPAddress ip(1,2,3,4) turns into 4.3.2.1 when sent on the wire via UDP (UDP.sendPacket) from firmware compiled by the particle cloud targeted to Argon w/ firmware 0.8.0-rc-25.

If needed I can do packet captures, but this must be some kind of HAL or endianness issue. I took a quick look at the github repos with the above tag, but didn’t see anything glaring unless this also affects TCP (seems unlikely given the low-level nature and that it communicates with the particle cloud just fine!). set_ipv4 and retrieval of IPAddress octet by index seems a little inconsistent (3-index) but I didn’t look too hard here.

Maybe this is just a cloud env/compiler bug, I didn’t dig into it further locally after confirming the work around const IPAddress ip(4,3,2,1) for now, moving onto playing with other features :wink:

Another item I ran into is the Argon seems to not boot when connected via USB power source-only (no serial lines connected). The only way it boots currently (progresses from dark blue flashing) is being connected to a laptop. I didn’t see anything obvious documented that would cause this… I tried disabling the Serial on the device during setup, but this appears to be something pre-setup() and pre-Wifi.ready().

Maybe I’m doing something wrong in both of these cases, but figured I’d drop a note into the forums regardless.

1 Like

Interesting findings.
Have you filed an issue about the IPAddress behaviour?

I can’t confirm your power issue tho’
Can you try to power the device via VUSB and GND - does it work then?
Could it be that your USB power is too weak or noisy compared to your laptop?

That Argon USB behavior is odd. I tried an Argon with both a data-block cable (power only) from a USB hub and also a standalone wall outlet charger and it seemed to work normally for me with no data connection.

I can confirm the byte ordering bug with UDP.sendPacket on my Boron running 0.8.0-rc.25. You should open a ticket.

I don’t have any problems with USB power on the Boron. It works fine whether I run if from a USB wall plug (power only) or connect it to the serial port on my laptop. (I mostly use it with the laptop so that I can use Serial.println for debugging)

rgr for UDP, thanks for confirming the ordering bug. Can file a ticket.

Regarding the USB Power issue – it has something to do with how I setup the Argon. Today, I performed a factory reset of the device and completed the app installation completely; it works as expected now. Previously I gave up after selecting “not mesh network” during the WiFi setup phase due to workflow issues that I’ll explain later; I then manually registered the device in the cloud. This must have left the device in a strange state that I’m not familiar.

When powered on with serial connections present, it would start blinking blue for 5 seconds or so, then transition to the expected green flash until it got an IP and breathed cyan after establishing a connection.

In the state described above, when powered on with a data-block (or via VUSB) cable, the device would blink blue forever. (I assume it was looking to pair or something even thought it was already setup?)

The app setup is very cumbersome for me as the wireless network registration requires per-device WPA2 passwords (if not via EAP-TLS). (An app workflow exposing a MAC address would make it easier, but still more cumbersome than the cli)

The firmware upload via BT is also a bit slow and I would prefer to do that via the particle cli/serial/usb, but I realize that isn’t a normal user request.

Appreciate the acks/feedback everyone.

Oh – forgot to add. particle serial mac returns all 00’s for argon’s it seems.

2 Likes

Yes I have also tried that. My argon cant connect to the cloud. It keeps flashing green really fast and in some flashes it goes red.

1 Like

If you’re unable to get the Argon to connect to the cloud, you should get a cloud debug log. The instructions are here:

1 Like

Thanks! But computer does not recognize argon in DFU mode. It shows like this in Device Manager
image

That problem can be solved by following the instructions here:

This is what I got

particle serial monitor
Opening serial monitor for com port: “COM6"
Serial monitor opened successfully:
0000005000 [system.nm] INFO: State changed: DISABLED -> IFACE_DOWN
configured credentials:
ssid=hofflich 2.4 security=unsecured cipher=0
available access points:
0000006305 [ncp.at] TRACE: > AT
0000006306 [ncp.at] TRACE: < AT
0000006306 [ncp.at] TRACE: < OK
0000007307 [hal] TRACE: NCP ready to accept AT commands
0000007307 [ncp.at] TRACE: > AT+CMUX=0
0000007308 [ncp.at] TRACE: < AT+CMUX=0
0000007310 [ncp.at] TRACE: < OK
0000007310 [gsm0710muxer] INFO: Starting GSM07.10 muxer
0000007312 [gsm0710muxer] INFO: Openning mux channel 0
0000007313 [gsm0710muxer] INFO: GSM07.10 muxer thread started
0000007364 [gsm0710muxer] INFO: Resuming channel 0
0000007364 [gsm0710muxer] INFO: Openning mux channel 1
0000007465 [gsm0710muxer] INFO: Resuming channel 1
0000007465 [gsm0710muxer] INFO: Resuming channel 1
0000007467 [ncp.at] TRACE: > AT
0000007517 [ncp.at] TRACE: < AT
0000007517 [ncp.at] TRACE: < OK
0000007518 [ncp.at] TRACE: > AT+CWDHCP=0,3
0000007567 [ncp.at] TRACE: < AT+CWDHCP=0,3
0000007568 [ncp.at] TRACE: < OK
0000007568 [hal] TRACE: NCP state changed: 1
0000007569 [net.esp32ncp] TRACE: NCP event 1
0000007571 [ncp.at] TRACE: > AT+CWLAP
0000007617 [ncp.at] TRACE: < AT+CWLAP
0000010118 [ncp.at] TRACE: < +CWLAP:(4,“hofflich 2.4”,-45,“24:f5:a2:66:2f:2a”,6)
SSID=hofflich 2.4 security=wpa2 channel=6 rssi=-45
0000010122 [ncp.at] TRACE: < +CWLAP:(3,“WIFI885F46”,-45,“30:f7:72:88:5f:4a”,11)
SSID=WIFI885F46 security=wpa2 channel=11 rssi=-45
0000010128 [ncp.at] TRACE: < +CWLAP:(3,“TG1672G52”,-55,“78:71:9c:4b:18:50”,6)
SSID=TG1672G52 security=wpa2 channel=6 rssi=-55
0000010131 [ncp.at] TRACE: < +CWLAP:(3,“TC8715DAB”,-56,“b4:2a:0e:45:e2:b1”,1)
SSID=TC8715DAB security=wpa2 channel=1 rssi=-56
0000010135 [ncp.at] TRACE: < +CWLAP:(3,“OhmDome”,-59,“78:29:ed:19:94:1f”,6)
SSID=OhmDome security=wpa2 channel=6 rssi=-59
0000010138 [ncp.at] TRACE: < +CWLAP:(3,“NETGEAR09”,-67,“9c:3d:cf:f7:9b:c7”,4)
SSID=NETGEAR09 security=wpa2 channel=4 rssi=-67
0000010141 [ncp.at] TRACE: < +CWLAP:(4,“belkin.bd9”,-68,“08:86:3b:5c:db:d9”,6)
SSID=belkin.bd9 security=wpa2 channel=6 rssi=-68
0000010143 [ncp.at] TRACE: < +CWLAP:(3,“HAMSHAKE”,-69,“14:2d:27:23:0b:e9”,6)
SSID=HAMSHAKE security=wpa2 channel=6 rssi=-69
0000010146 [ncp.at] TRACE: < +CWLAP:(3,”",-70,“2c:30:33:ff:b4:d5”,3)
SSID= security=wpa2 channel=3 rssi=-70
0000010149 [ncp.at] TRACE: < +CWLAP:(3,“Hot Ass Mess”,-71,“20:4e:7f:82:6a:08”,11)
SSID=Hot Ass Mess security=wpa2 channel=11 rssi=-71
0000010152 [ncp.at] TRACE: < +CWLAP:(3,“DG1670A82”,-73,“60:19:71:e5:6b:80”,6)
SSID=DG1670A82 security=wpa2 channel=6 rssi=-73
0000010155 [ncp.at] TRACE: < +CWLAP:(3,"",-74,“4e:ef:c0:ad:b6:40”,1)
SSID= security=wpa2 channel=1 rssi=-74
0000010157 [ncp.at] TRACE: < +CWLAP:(3,“TG1672G82”,-75,“60:19:71:c4:2f:80”,6)
SSID=TG1672G82 security=wpa2 channel=6 rssi=-75
0000010161 [ncp.at] TRACE: < +CWLAP:(3,“Pretty Fly for a WiFi”,-75,“60:38:e0:85:40:9c”,8)
SSID=Pretty Fly for a WiFi security=wpa2 channel=8 rssi=-75
0000010164 [ncp.at] TRACE: < +CWLAP:(3,“jasper”,-76,“60:38:e0:8f:8d:dd”,9)
SSID=jasper security=wpa2 channel=9 rssi=-76
0000010167 [ncp.at] TRACE: < +CWLAP:(3,“NETGEAR66”,-79,“44:94:fc:4f:67:5f”,8)
SSID=NETGEAR66 security=wpa2 channel=8 rssi=-79
0000010170 [ncp.at] TRACE: < +CWLAP:(4,“mb550”,-79,“c0:c1:c0:64:82:6a”,11)
SSID=mb550 security=wpa2 channel=11 rssi=-79
0000010173 [ncp.at] TRACE: < +CWLAP:(3,“MAXMAD”,-81,“a0:04:60:a6:57:30”,2)
SSID=MAXMAD security=wpa2 channel=2 rssi=-81
0000010176 [ncp.at] TRACE: < +CWLAP:(3,“Straylight”,-81,“f4:f2:6d:ac:0a:7d”,6)
SSID=Straylight security=wpa2 channel=6 rssi=-81
0000010178 [ncp.at] TRACE: < +CWLAP:(0,“HP-Print-65-LaserJet 100”,-83,“68:94:23:c0:1c:65”,11)
SSID=HP-Print-65-LaserJet 100 security=unsecured channel=11 rssi=-83
0000010183 [ncp.at] TRACE: < +CWLAP:(3,“ShittyWifi”,-84,“cc:40:d0:0f:db:29”,5)
SSID=ShittyWifi security=wpa2 channel=5 rssi=-84
0000010186 [ncp.at] TRACE: < +CWLAP:(3,“NETGEAR31”,-84,“a0:63:91:a4:5e:3f”,6)
SSID=NETGEAR31 security=wpa2 channel=6 rssi=-84
0000010190 [ncp.at] TRACE: < +CWLAP:(3,“NETGEAR10”,-86,“08:02:8e:e2:c8:fd”,1)
SSID=NETGEAR10 security=wpa2 channel=1 rssi=-86
0000010193 [ncp.at] TRACE: < +CWLAP:(0,“HP-Print-a6-LaserJet 200 color”,-86,“7c:e9:d3:99:55:a6”,11)
SSID=HP-Print-a6-LaserJet 200 color security=unsecured channel=11 rssi=-86
0000010197 [ncp.at] TRACE: < +CWLAP:(0,"",-88,“fa:8f:ca:7b:1a:06”,1)
SSID= security=unsecured channel=1 rssi=-88
0000010199 [ncp.at] TRACE: < +CWLAP:(3,“anderson”,-88,“a8:6b:ad:e0:21:41”,11)
SSID=anderson security=wpa2 channel=11 rssi=-88
0000010202 [ncp.at] TRACE: < +CWLAP:(3,“TG1672GD2”,-89,“d4:05:98:26:de:d0”,1)
SSID=TG1672GD2 security=wpa2 channel=1 rssi=-89
0000010206 [ncp.at] TRACE: < +CWLAP:(3,“WiFiFu”,-90,“24:a2:e1:f1:14:e0”,11)
SSID=WiFiFu security=wpa2 channel=11 rssi=-90
0000010209 [ncp.at] TRACE: < +CWLAP:(3,“DG860AD2”,-91,“c4:8e:8f:e6:a5:7d”,11)
SSID=DG860AD2 security=wpa2 channel=11 rssi=-91
0000010213 [ncp.at] TRACE: < +CWLAP:(3,“NETGEAR75”,-93,“9c:3d:cf:ce:24:28”,10)
SSID=NETGEAR75 security=wpa2 channel=10 rssi=-93
0000010216 [ncp.at] TRACE: < OK
connecting to WiFi
0000010223 [system.nm] INFO: State changed: IFACE_DOWN -> IFACE_REQUEST_UP
0000010227 [net.ifapi] INFO: Netif wl3 state UP
0000010228 [ncp.at] TRACE: > AT+GETMAC=0
0000010230 [system.nm] INFO: State changed: IFACE_REQUEST_UP -> IFACE_UP
0000010279 [ncp.at] TRACE: < AT+GETMAC=0
0000010279 [ncp.at] TRACE: < +GETMAC: "30:ae:a4:d1:62:2c"
0000010280 [ncp.at] TRACE: < OK
0000010283 [gsm0710muxer] INFO: Openning mux channel 2
0000010379 [gsm0710muxer] INFO: Resuming channel 2
0000010380 [ncp.at] TRACE: > AT+CWJAP=“hofflich 2.4”,“2615D448DADB43A24”,"24:f5:a2:66:2f:2a"
0000010431 [ncp.at] TRACE: < AT+CWJAP=“hofflich 2.4”,“PASSWORD”,"24:f5:a2:66:2f:2a"
0000013331 [ncp.at] TRACE: < WIFI CONNECTED
0000014281 [ncp.at] TRACE: < OK
0000014281 [hal] TRACE: NCP connection state changed: 2
0000014282 [net.esp32ncp] TRACE: NCP event 2
0000014284 [net.esp32ncp] TRACE: State changed event: 2
0000014285 [net.ifapi] INFO: Netif wl3 link UP
0000014286 [system.nm] INFO: State changed: IFACE_UP -> IFACE_LINK_UP

That’s what I get when my DHCP server tries to assign an IPv6 to the Argon (or merely checks whether IPv6 is supported on the device?).
Currently my workaround is to add an intermediate WiFi router where I can disable IPv6 support entirely.
Hopefully 0.8.0-rc.26 will address this issue.

3 Likes

I have access to my router config, it is a linksys E2500. So would you recommend me to disable IPv6?

Thanks!

It’s worth a try.
However, I can disable IPv6 on my cable modem, but for some reason this doesn’t prevent the modem from still trying it :see_no_evil:

1 Like

Interesting - I was having the trouble with my xenon gateway on ethernet featherwing not getting the particle cloud connection to connected mesh devices.
I put the intermediate router in (Apple TimeCapsule), but did not disable IPv6, just set the TC to use the same DNS servers as the Xfinity Arris modem that seems to be causing the trouble.
That did the trick for me, but I’m not certain that we’re definitely dealing with the same issue.
J

I think everyone is dealing with the same issue haha.

Okay so A friendo of mine helped me to work this through. What we did was to disable IPv6 from my linksys router, then selecting a specific network mode, in my case was I think G and then we selected a channel, we picked a random number 4 which was 2.47 ghz.

Then I restarted the computer, and connected my laptop to the 2.4 network. Then used my laptop as a hotspot, and used that network to connect my argon. That did the trick for me. Although far from ideal, at least now I can start doing some stuff while Particle folks fix this issue.

Hopeflly soon. This will start to get more chaotic as more orders get fulfilled, speaking about a rough start huh! haha

Regards

1 Like

same here

Thanks all - we’re working currently on a single thread where we can identify, track, and resolve issues like this one that should be live today or tomorrow.

Thank you for your patience and taking the time to report these issues so that we can investigate and implement a fix.

3 Likes

I have the same issue.
Not using IPv6. Using pfSense DHCP Server and I could see the IP leased from the server as bellow.

Nov 29 21:47:54 dhcpd DHCPDISCOVER from 30:ae:a4:d1:c1:1c via xn0
Nov 29 21:47:55 dhcpd DHCPOFFER on 192.168.0.143 to 30:ae:a4:d1:c1:1c via xn0
Nov 29 21:48:27 dhcpd DHCPDISCOVER from 30:ae:a4:d1:c1:1c via xn0
Nov 29 21:48:27 dhcpd DHCPOFFER on 192.168.0.143 to 30:ae:a4:d1:c1:1c via xn0
Nov 29 21:49:00 dhcpd DHCPDISCOVER from 30:ae:a4:d1:c1:1c via xn0
Nov 29 21:49:00 dhcpd DHCPOFFER on 192.168.0.143 to 30:ae:a4:d1:c1:1c via xn0
Nov 29 21:49:32 dhcpd DHCPDISCOVER from 30:ae:a4:d1:c1:1c via xn0
Nov 29 21:49:32 dhcpd DHCPOFFER on 192.168.0.143 to 30:ae:a4:d1:c1:1c via xn0

Also I could detect the IP active for few moments before the board restart.

Bellow my serial output:

MacLC:argon lamaral$ particle serial monitor
Opening serial monitor for com port: “/dev/tty.usbmodem14101"
Serial monitor opened successfully:
0000005000 [system.nm] INFO: State changed: DISABLED -> IFACE_DOWN
configured credentials:
ssid=SKYNET security=wpa2 cipher=0
available access points:
0000006305 [ncp.at] TRACE: > AT
0000006306 [ncp.at] TRACE: < AT
0000006307 [ncp.at] TRACE: < OK
0000007307 [hal] TRACE: NCP ready to accept AT commands
0000007308 [ncp.at] TRACE: > AT+CMUX=0
0000007309 [ncp.at] TRACE: < AT+CMUX=0
0000007310 [ncp.at] TRACE: < OK
0000007311 [gsm0710muxer] INFO: Starting GSM07.10 muxer
0000007312 [gsm0710muxer] INFO: Openning mux channel 0
0000007313 [gsm0710muxer] INFO: GSM07.10 muxer thread started
0000007365 [gsm0710muxer] INFO: Resuming channel 0
0000007366 [gsm0710muxer] INFO: Openning mux channel 1
0000007467 [gsm0710muxer] INFO: Resuming channel 1
0000007468 [gsm0710muxer] INFO: Resuming channel 1
0000007469 [ncp.at] TRACE: > AT
0000007520 [ncp.at] TRACE: < AT
0000007521 [ncp.at] TRACE: < OK
0000007521 [ncp.at] TRACE: > AT+CWDHCP=0,3
0000007570 [ncp.at] TRACE: < AT+CWDHCP=0,3
0000007571 [ncp.at] TRACE: < OK
0000007572 [hal] TRACE: NCP state changed: 1
0000007572 [net.esp32ncp] TRACE: NCP event 1
0000007573 [ncp.at] TRACE: > AT+CWLAP
0000007620 [ncp.at] TRACE: < AT+CWLAP
0000010121 [ncp.at] TRACE: < +CWLAP:(3,“SKYNET”,-45,“f4:f2:6d:70:e7:3d”,6)
SSID=SKYNET security=wpa2 channel=6 rssi=-45
0000010125 [ncp.at] TRACE: < +CWLAP:(3,”",-52,“b8:a1:75:24:be:1f”,6)
SSID= security=wpa2 channel=6 rssi=-52
0000010128 [ncp.at] TRACE: < +CWLAP:(2,“seti”,-62,“a0:a3:e2:c7:9b:e5”,11)
SSID=seti security=wpa channel=11 rssi=-62
0000010130 [ncp.at] TRACE: < +CWLAP:(4,“GladPad”,-81,“a0:a3:e2:44:a0:c5”,11)
SSID=GladPad security=wpa2 channel=11 rssi=-81
0000010133 [ncp.at] TRACE: < +CWLAP:(3,“NETGEAR10”,-84,“9c:d3:6d:b3:fa:72”,7)
SSID=NETGEAR10 security=wpa2 channel=7 rssi=-84
0000010135 [ncp.at] TRACE: < +CWLAP:(3,“NETGEAR75”,-85,“08:02:8e:7e:15:8b”,1)
SSID=NETGEAR75 security=wpa2 channel=1 rssi=-85
0000010138 [ncp.at] TRACE: < +CWLAP:(3,"",-88,“84:17:ef:89:8b:86”,1)
SSID= security=wpa2 channel=1 rssi=-88
0000010140 [ncp.at] TRACE: < +CWLAP:(0,“xfinitywifi”,-88,“92:ad:43:5f:9b:d8”,6)
SSID=xfinitywifi security=unsecured channel=6 rssi=-88
0000010143 [ncp.at] TRACE: < +CWLAP:(5,"",-88,“9e:ad:43:5f:9b:d8”,6)
SSID= security=unsecured channel=6 rssi=-88
0000010145 [ncp.at] TRACE: < +CWLAP:(4,"",-89,“96:ad:43:5f:9b:d8”,6)
SSID= security=wpa2 channel=6 rssi=-89
0000010148 [ncp.at] TRACE: < +CWLAP:(0,“xfinitywifi”,-90,“b6:ca:b5:de:ea:f0”,1)
SSID=xfinitywifi security=unsecured channel=1 rssi=-90
0000010151 [ncp.at] TRACE: < +CWLAP:(3,“TP-LINK_B969”,-90,“18:a6:f7:56:b9:69”,3)
SSID=TP-LINK_B969 security=wpa2 channel=3 rssi=-90
0000010154 [ncp.at] TRACE: < +CWLAP:(4,“Brrraaappp”,-90,“04:bf:6d:a2:63:46”,11)
SSID=Brrraaappp security=wpa2 channel=11 rssi=-90
0000010157 [ncp.at] TRACE: < +CWLAP:(4,“HOME-EAF2”,-91,“bc:ca:b5:de:ea:f0”,1)
SSID=HOME-EAF2 security=wpa2 channel=1 rssi=-91
0000010159 [ncp.at] TRACE: < +CWLAP:(0,“HP-Print-97-ENVY 4500 series”,-94,“30:8d:99:b5:61:97”,1)
SSID=HP-Print-97-ENVY 4500 series security=unsecured channel=1 rssi=-94
0000010162 [ncp.at] TRACE: < +CWLAP:(3,“Outbreak Shelter”,-94,“9c:34:26:8b:73:a8”,1)
SSID=Outbreak Shelter security=wpa2 channel=1 rssi=-94
0000010165 [ncp.at] TRACE: < OK
connecting to WiFi
0000010172 [system.nm] INFO: State changed: IFACE_DOWN -> IFACE_REQUEST_UP
0000010175 [net.ifapi] INFO: Netif wl3 state UP
0000010176 [ncp.at] TRACE: > AT+GETMAC=0
0000010178 [system.nm] INFO: State changed: IFACE_REQUEST_UP -> IFACE_UP
0000010226 [ncp.at] TRACE: < AT+GETMAC=0
0000010227 [ncp.at] TRACE: < +GETMAC: “30:ae:a4:d1:c1:1c"
0000010228 [ncp.at] TRACE: < OK
0000010231 [gsm0710muxer] INFO: Openning mux channel 2
0000010326 [gsm0710muxer] INFO: Resuming channel 2
0000010327 [ncp.at] TRACE: > AT+CWJAP=“SKYNET”,”[password]",“f4:f2:6d:70:e7:3d"
0000010378 [ncp.at] TRACE: < AT+CWJAP=“SKYNET”,”[password]","f4:f2:6d:70:e7:3d"
0000013278 [ncp.at] TRACE: < WIFI CONNECTED
0000014228 [ncp.at] TRACE: < OK
0000014229 [hal] TRACE: NCP connection state changed: 2
0000014230 [net.esp32ncp] TRACE: NCP event 2
0000014231 [net.esp32ncp] TRACE: State changed event: 2
0000014233 [net.ifapi] INFO: Netif wl3 link UP
0000014235 [system.nm] INFO: State changed: IFACE_UP -> IFACE_LINK_UP
Serial connection closed.
MacLC:argon lamaral$

I also have a ticket id 70831 open to troubleshot this issue.

1 Like

One more thing. I have confirmed the issue happens using following to setup:

  • Android device
  • Serial configuration (w)
  • particle cli

All are showing the same issue.

Also I manage to setup a home (consumer) wifi router connected to the same network, but with the router DHCP enabled, and I could confirm the issue is related to the DHCP resolution.

I can easily reproduce the issue.