I just updated my Argon with the long awaited firmware update 0.8.0-rc.26 that was just released, hoping it will solve the wifi connectivity issue and finally make the Argon usable. Alas I still see the same red flashes although at a reduced frequency now… some progress is still better than nothing I guess.
When do they happen?
What code are you running at the time?
1 Like
It happened with tinker code, the one included as a binary in the release. I didn’t even bother to reflash my test application. And it happens every 2 minutes or so, I didn’t time it yet and didn’t look into any trace logs.
I honestly got frustrated to see that the update didn’t solve this problem like announced. It’s been now a series of frustrations with 3rd gen devices and may be I just reached the limit of my patience. I respect your efforts @ScruffR and other community members for doing your best to help us figure out how to solve different issues with mesh devices, but we (I) have to admit that they are not yet ready for deployment in any maker project for now.
1 Like
I took another stab at it:
1- I cloud compiled a test application that exposes a cloud function to switch on/off a relay and enabled logging at trace level and… so far so good, it’s been running for > 20 minutes and no crash at all.
In this test code, I use SYSTEM_MODE(SEMI_AUTOMATIC) and at the end of Setup() I added:
WiFi.on();
WiFi.connect();
Particle.connect();
Every 30 seconds the following exchange is reported: (wifi keep alive?)
0000645137 [comm.protocol] TRACE: Reply recieved: type=2, code=0
0000645139 [comm.protocol] INFO: message id 96 complete with code 0.00
0000645141 [comm.protocol] INFO: rcv’d message type=13
the message id is incremented by one .
The Xenon that was previously setup to connect to this Argon gateway was just blinking green and I take it that no mesh network is available to connect to.
2- I further added:
Mesh.on();
Mesh.connect();
at the end of setup, right before WiFi.on()
I can see in the logs that a mesh network is started:
0000002207 [app] INFO: Starting up…
0000002208 [system.nm] INFO: State changed: DISABLED -> IFACE_DOWN
0000002217 [system.nm] INFO: State changed: IFACE_DOWN -> IFACE_REQUEST_UP
0000002221 [net.ifapi] INFO: Netif th1 state UP
0000002221 [net.th] INFO: Bringing OpenThreadNetif down
0000002223 [net.th] INFO: Bringing OpenThreadNetif up
> 0000002224 [net.th] INFO: Network name: nrjyMesh
0000002225 [net.th] INFO: 802.15.4 channel: 12
0000002226 [net.th] INFO: 802.15.4 PAN ID: 0x0d68
0000002330 [system.nm] INFO: State changed: IFACE_REQUEST_UP -> IFACE_UP
0000002440 [net.th] TRACE: OpenThread state changed: 4
0000002441 [net.th] TRACE: OT_CHANGED_THREAD_ROLE
0000002443 [system.ot] INFO: Role changed: detached
0000002451 [net.ifapi] INFO: Netif wl3 state UP
0000003750 [ncp.at] TRACE: > AT
…
and then the “panic,7 red flashes” is back again. On the log output there is no error reported or anything related. The last message on the console is the latest keep alive exchange:
0000105422 [comm.protocol] TRACE: Reply recieved: type=2, code=0
0000105422 [comm.protocol] INFO: message id 258 complete with code 0.00
0000105424 [comm.protocol] INFO: rcv’d message type=13
and it keeps going like that every ~2min and 20 sec.
So for now, I’ll just stick to using the Argon like a Photon 
1 Like
Same issue here. One of my Xenons is rock solid and the other does the SOS-7 every couple of minutes. Both are in a Mesh with an Argon running the Marco/Polo code.
Thank you for providing debug logs! It sounds like rc.26 didn’t resolve all of your issues, but I’m glad to hear that there’s some improvement.
We have a team of folks who are looking to dive back into new issues now that rc.26 is released. If either of you are willing to provide your code here in thread or to me over PM, we can attempt to reproduce the issue so we can identify and fix it for a future release.
Also make sure you are targeting rc.26 as the compile target in the Web IDE – that seems to have resolved the issue for another user experiencing similar symptoms.
1 Like
The OP’s screen capture shows RC.26 but as I saw when upgrading devices, the “Device OS:” in the header does not update after a flash. I tried doing a Ping, Device Vitals refresh and Variables refresh none of which updated the header on the device page. I had to click on another area of the console and then come back to the device page to see that the Device OS had upgraded.
2 Likes
Just flashed the user firmware once again to make sure. I’m still getting an SOS every 2:30 or so. I don’t think you’ll be able to recreate the issue as I have another Xenon running perfectly with the same code.
Do you want the device sent back so you can debug it?
Kev
I’m also having some issues with Argons on rc-26 - not quite as drastic as yours, @jaafar .
I have an Argon + Xenon mesh, a Boron + Xenon mesh, a Xenon (ethernet) + Xenon mesh, and a stand alone Argon and stand alone Boron running. Everything but the Argons and the connected Xenon have been running 18 hours on the latest release with no hiccups.
The two argons Both show a number (5 or more) disconnect events overnight, as well as the Xenon connected to the Argon. The stand alone argon won’t update it’s device vitals, even though when I hit refresh, it does send the spark/device/diagnostics/update publish. The Argons do everything else I’m currently expecting of them. The other devices show no disconnect events. Everything has very strong signal, and not much else electronic going on around them.
A small side note, where my Argons have the disconnect events, the device vitals seem to think the Argons are Borons, as it says that I should move it to a place with better cellular signal due to disconnecting from the Particle Cloud too often.
A small side note, where my Argons have the disconnect events, the device vitals seem to think the Argons are Borons, as it says that I should move it to a place with better cellular signal due to disconnecting from the Particle Cloud too often.
That could just be a typo in a debug or error string somewhere, but I would like to investigate this further regardless. Could you provide the full error string verbatim? I’d like to pass that along to my engineering team so we can dig into that one further.
Thanks
Dec 13th, 2018, 02:35AM
Here you go, cut and paste from the device vitals box of the Argon.
5 disconnect events
The device is disconnecting from the Particle Cloud too frequently. Large numbers of cloud disconnects are often caused by poor signal strength or network congestion. If possible, move the device to a place with better Cellular signal.
296ms round-trip time
0 rate-limited publishes
84kB of 167kB RAM used
Download History Run diagnostics
UPDATE: I’ve uploaded new binaries that enable logging from an ISR.
I would appreciate if you could flash the following debug system firmware. They will automatically log on Serial1 @ 115200, you should not instantiate Serial1LogHandler in the user application. Unfortunately we cannot reliably log from an ISR to Serial. If you don’t have an UART-USB adapter, you can use another device running a simple app and connecting its RX to TX of the device being debugged.
SYSTEM_MODE(MANUAL);
void setup(void) {
Serial1.begin(115200);
Serial.begin();
while (true) {
while (Serial1.available() > 0 && Serial.availableForWrite() > 0) {
Serial.write(Serial1.read());
}
}
}
@avtolstoy I’ve sent you a log file by DM. This is the error message that was associated with the red flashes:
0000122304 [hal] ERROR: Assertion failed: openthread/third_party/NordicSemiconductor/drivers/radio/raal/softdevice/nrf_raal_softdevice.c:236 timer_jitter_adjust (cc_margin > rtc_tick~
!
UPDATE: editing the subject of this thread as this problem is now solved in 0.8.0-rc.27
2 Likes