Electron (0.5.3) in safe mode

electron
Tags: #<Tag:0x00007f1ca585aea8>

#1

ADMIN NOTE - Moved from Updates for the Status Incident of May 3rd

Hello @mstanley,
Thank you for giving clarification regarding the issue. I am using electron device OS(0.5.3) and it is blinking magenta(red+blue) hope it is in safe mode even I have removed and gave power again. The device is not getting connected to the cloud . My question is how to come out of safe mode I have tried with reset and mode buttons as well but didn’t work for me.


Updates for the Status Incident of May 3rd
#2

If your device is entering safe mode, that suggests to me that either the user application or device OS is in a corrupted state. It’s likely you’re experiencing something else than what we are seeing at this point. It isn’t to say that this incident may have been the catalyst though.

0.5.3 is an older device OS version. I’d really recommend upgrading if at all possible. At minimum, I’d recommend 0.7.0–but if you are not maxing out available RAM and flash with your user application, consider moving to the latest device OS version v1.2.0-beta.1

You can try to flash device OS and user application through the web IDE, but if that doesn’t take, you may need to try it in DFU mode. If you aren’t familiar with the steps taken to flash over DFU, please feel free to ask here, through our support portal, or as a new topic on our community.


#3

Hi @mstanley,
I have resolved my device safe mode issue by following some steps. The thing that I’m not using web IDE is I’m facing error while flashing the code stating server-has-failed-to-process-the-request-on-time-please-try-again. So, I have just started working on workbench of particle.


#4

As a part of some upgrades on the backend infrastructure, rate limits were migrated as well–and not all of them are behaving as expected. It’s possible this may have impacted the Web IDE inadvertently.

A fix should be going out today to handle the issues with API rate limiting. After today, I anticipate the issues you are seeing will be resolved. If you are still experiencing issues in the next day or two with the web IDE or any other tools relating to the API, be sure to let us know here.


#5

Thank you will update you after checking. Actually while I’m using the workbench in VS code while compiling the basic led program getting the error like

fatal: not a git repository (or any of the parent directories): .git
fatal: not a git repository (or any of the parent directories): .git
make[2]: /home/miracle/.particle/toolchains/gcc-arm/5.3.1/bin/arm-none-eabi-gcc: Command not found
/home/miracle/.particle/toolchains/deviceOS/1.0.1/firmware-1.0.1/build/arm-tools.mk:42: *** "ARM gcc version 5.3.1 or later required, but found ". Stop.
make[1]: *** [modules/photon/user-part] Error 2
make: *** [compile-user] Error 2
The terminal process terminated with exit code: 2

Can I know why we are getting the basic issues many times like while compiling and flashing the code due to this unable to proceed the usecases .


#6

0.5.3 is really ancient and has some major short comings, hence 0.5.5 is the oldest version available on Particel Workbench

And your error report also suggests you don’t target 0.5.3 but 1.0.1

Consequently flashing a 1.0.1 binary to a 0.5.3 device is expected to enter Safe Mode to upgrade the device OS via Safe Mode Healer.

One possible answer: “When tools are not used as intended injuries are to be expected”


#7

Consequently flashing a 1.0.1 binary to a 0.5.3 device is expected to enter Safe Mode to upgrade the device OS via Safe Mode Healer.

Means I’m using the 1.0.1 OS target version now even no use I didn’t get you how to solve.


#8

In Particle Workbench you can hit Ctrl+Shift+P and then enter
image
and select the version you actually want to target.

I’d also suggest you update your device via CLI in DFU Mode (particle update)


#9

Just a note about safe mode healer:

The device will automatically enter safe mode in order to bring the device OS up to the binary version. Because your device is on such an old version, the safe mode healer will do several incremental upgrades. Each step in the process will take a minute or two (maybe 5-10 minutes total). I’ve had devices look stuck but it was just a super long safe mode healer process. Are you being patient enough and allowing the automatic upgrade process to complete? It may appear your device becomes unresponsive and stuck in safe mode but rather the device is still doing what it should. If you assumed the process was stuck and tried to interfere, then that may have actually caused the process to stall permanently. You can also do a particle serial inspect to see the module versions on the device.


#10

Hi @ScruffR, @ninjatill
Actually to come out of safe mode I have waited for couple of days by following some instructions I have solved that. The thing is I’m using workbench with updates version of particle i.e 1.0.0 and can compile successfully using command pallet (ctrl+shift+p) but couldnot flash successfully even for a sample program that is timed out and failed to flash the device . I have updated my particle as well in DFU mode.


#11

If you have a binary created by Workbench you can use particle binary inspect <firmware.bin> to check that binary.
This in connection with the info acquired via particle serial inspect (as pointed out by @ninjatill) may help understanding what’s wrong.

If the binary would in fact be compatible with your device’s current state then you can try flashing it in DFU mode via particle flash --usb <firmware.bin> -v.
If that doesn’t help you can post the output of that command for more info again.

BTW, in order to have Workbench flash your newly built project your device needs to be connected via USB and in DFU Mode.


#12

Hi,
Intended injuries are to be expected… Sorry, Didn’t get you properly.


#13

Not “intended injuries” but “not used as intended” then “‘injuries’ can be expected” :wink:


#14

Hi @mstanley and @ScruffR I’ve uploaded programs in safe mode and seemed to temporarily resolve my issue but then errored out to a solid cyan again. and am also having additional issues here with i2c : Casting Variables for I2C I have also updated my software in DFU mode but have gotten the same results for this Safe Mode issue. How can I find out what version I’m using on my particle electron?


#15

You can put your device in Listening Mode and run either particle serial identify or particle serial inspect


#16

@ScruffR I am either getting “Serial Timed out” or “Could not get inspect device:Serial timed out” errors depending on what command I run. I do see that my Electron is showing up in my device manager on my Windows machine. Hitting the reset button also does not help. Thoughts?


#17

Is the device in Listening Mode (blinking blue) at the time?

You can also look at console.particle.io/devices to see the last installed version the cloud knows about.
Or you can put the device in Safe Mode and post the event that gets sent to console.particle.io/events when the device connects to the cloud.

However, running particle update -v in DFU Mode should ensure you are on the most recent stable version.

BTW, check whether particle --version gives you 1.40.1 (or higher if you read this later) - otherwise, run particle update-cli


#18

I figured out that it was not an issue with my CLI interface, rather a line of code I was dealing with. Something with my Wire.endTransmission() caused an error. I couldn’t clear the error until I reuploaded a blank bin file in safe mode. Very weird issue that I’ve never seen before.

It was not in Listening mode, I couldn’t get it to listen until I figured out the above wire.endTransmission() :slight_smile: Why would that statement cause a mode change?


#19

It wouldn’t, but the CLI commands expect the device to be in Listening Mode to work.
And your wire.endTransmission() issue may well cause the device to be unable entering LM via the button due to some blocking behaviour.
It shouldn’t prevent Safe Mode tho’


Casting Variables for I2C