Xenon keeps restarting


#1

I have a sketch running on a Xenon. I am using Mesh.publish every 10 seconds and an Argon is receiving the message sent by that Xenon.

Every about three minutes, the Xenon flashes red then restarts. Here is my code

    tMessage = ("$$," + String(77) + "," + String(unitNum)  + "," + String(myDist)  + ",0,0,0,0," + "^");
    byte bMessage[tMessage.length()];
    tMessage.getBytes(bMessage, tMessage.length() + 1);
    //retVal = Mesh.publish("SensorData", tMessage);

What may be causing this behavior?

I am powering board using regulated 5V to VUSB. I did notice that the board gets rather hot …

Update:

I commented out Mesh.publish but the board still restarts every about 3 minutes? Is there a way to trap what is causing this behavior?


#2

Your array would need to be one byte longer than the length of the string - after all you even use the +1 in the transfer call.


#3

Thank you @Scruffr but it must be something else as the same code was running before on a Bluz and should not cause a reboot.

I also took out that entire section but the system is sill rebooting every about 3 minutes …

Very puzzling.


#4

Hey @ScruffR I also have this problem, mine is running factory firmware, I haven’t flashed new to it yet. May be a hardware problem.


#5

I am confirming that there is something wrong with the hardware.

I just loaded Tinker and the Xenon is restarting every few minutes so it is not something related to my sketch.

That Xenon is in a mesh network with an Argon.


#6

If it did run before does not in any way mean the code was not wrong.
There are circumstances were coding errors won’t cause harm but they are still errors.
The compilers and/or optimizers might mitigate some effects on one platform but not on the other.

If you are 100% sure it’s only running vanilla Tinker with a clean device OS (including bootloader), then a HW issue is most likely.

A particle serial inspect log would be good to see.


#7

Here is the log for mine:

Platform: 14
Modules
  Bootloader module #0 - version 214, main location, 49152 bytes max size
    Integrity: PASS
    Address Range: PASS
    Platform: PASS
    Dependencies: PASS
  System module #1 - version 324, main location, 671744 bytes max size
    Integrity: PASS
    Address Range: PASS
    Platform: PASS
    Dependencies: PASS
      Bootloader module #0 - version 101
      undefined module #0 - version 0
  User module #1 - version 5, main location, 131072 bytes max size
    UUID: DA843B8BBE4ABEC1EFB0C66238B86CE68FFE7C613065143710018866E2954AB5
    Integrity: PASS
    Address Range: PASS
    Platform: PASS
    Dependencies: PASS
      System module #1 - version 324
      undefined module #0 - version 0
  empty - factory location, 131072 bytes max size

#8

I do not even know how to mess with the OS or the bootloader, and vanilla tinker has still been restarting every couple of minutes. See below:


#9

Hi @Mjones,

Do you have an Arris modem? I am having the same problems and have an Arris modem.

Also see:


#10

I do have an arris modem, I turned off IPV6 routing and this seemed to have stabilized the connection so that it can reconnect to the mesh network, but continues to disconnect. Before turning that off it would disconnect and never reconnect until I power cycled the Argon.


#11

I just checked my modem. My IPV6 routing was off and my Argon did not appear to be losing connection but the Xenon connected to it keeps restarting in my case every 2 minutes (+ 13 -14 seconds).


Xenon resets - 7 Red flashes after SOS
#12

Is there another wlan you can try – e.g. a mobile device’s hotspot?


#13

Thank you @ParticleD. Will try to find one and report.


#14

That’s the issue with many people, as of now. We’re trying to get it resolved.


#15

So what is the status of your Mesh network now?

Still getting frequent xenon disconnects with the IPV6 turned off?

I’m going to be initially testing from Smartphone hotspots so I have no idea if they use the IPV6 routing. If they do there is no way to turn it off so hopefully not.

Should be able to test this before the end of the week if the shipping happens as scheduled.


#16

As of last power down, this morning, my mesh network still had intermittent loss. This continued after IPv 6 was completely turned off in my router (as far as I can tell through the GUI).


#17

Update:

I was supplying regulated power (5V) via VUSB and GND. This afternoon, I found a power supply mistake in my wiring (which explains why the board got a bit hot).

The wiring was fixed and now I am having a stable mesh network. I will continue to monitor.

Here are the remaining problems:

  1. Sometimes, when updating Argon/Boron firmware, Xenons also flash Magenta!

  2. When Argon/Boron is reset (via System.reset and without power cycle), Xenons in the mesh never restart. They keep flashing cyan rapidly followed by a couple of yellow or red flashes, then fast cyan for a while …


#18

Are people still experiencing this SOS 7 “Exit” issue? I have one Xenon which reboots itself about every two minutes with red LED blinking seven times. It doesn’t matter which sketch I’m using, I’m seeing this with empty loop() and setup() as well. This also happened with rc-25 and now with rc-26.

Also the Xenon does this if it has been set up to Boron mesh or Argon mesh - no matter, and the setup sequence of Xenons to the mesh network doesn’t also matter. I have also tried changing the power supply / using USB only. Nothing seems to help.


#19

Hello folks,

Wanted to follow-up with this thread to let everyone know that a fix for the SOS-7 issue has been released with v0.8.0-rc.27. The issues was tracked to a problem with the Nordic 802.15.4 driver. Instructions for upgrading are available below. We’d love to know if applying the release fixes the issue SOS-7 issue that you’re experiencing.


Note that we have seen some reports of change in behavior for rc.27 when users call the Mesh.subscribe() function within the setup() loop that can result in a separate SOS-10 code which we’re currently investigating. If this issue affects you, please note the following workaround.