Breathing Magenta


#1

Does anyone know if the particle boards are generally unstable or have a high production failure rate or something?

I took delivery of 3. My first one kindof worked after about an hour of setup, for about 30 minutes - I played with tinker, got an LED flashing, and saw it upload a few things to the cloud a couple of times - a few days later, it no longer connects to the cloud ever again. My second and third ones seem to set up, but aside from one single status update to the cloud one time, have never worked.

After a ton of reboots, and all kind of re-loading different wifi networks, all different kinds of resets etc - nothing - the best I can get is “breathing magenta”.

Is there a way to use these things even if the wifi is screwing up? Can I program them over USB like a normal arduino, and if so, how do I compile and upload ?

What are all the known things that cause breathing-magenta? If it’s something my or my network or power or whatever-else are doing, I’d prefer to fix the probem of course…


#2

Breathing magenta indicates that no user-firmware is running (safe mode). The system firmware still runs and can connect to the cloud, as to allow you to update your firmware. Breathing magenta can be caused by using the setup/reset combination, by flashing firmware that can’t be run on the photon. That can be because it’s accidentally compiled for a Core (make sure you target the Photon when compiling). Some strange errors can cause a user firmware not to be accepted (corrupted files). There’s an inbuilt protection in the system firmware which verifies that the user-firmware is okay to run, if I’m not mistaken. Discrepancies between system/user firmware might also be a cause of malfunctioning. As long as the system firmware version is higher than the user firmware, you should be okay.

Just so I’ve said it; Although the Particle devices share a lot of similarities with Arduino, they are not actually Arduinos. They aren’t some kind of ‘special Arduinos’, thus there is no ‘normal Arduino’.
That said, I know what you mean, and yes, you can program them over USB similar to how you’d go about that with an Arduino :wink:
You can download a compiled .bin file from the web IDE, and flash that using the CLI. You could also write your code locally and compile it on the cloud servers using the CLI. Alternatively, you could also set up a local toolchain, and use that to program it. The latter would also allow you to program the system firmware, opening up all the possibilities, and giving you the most flexibility, as long as you know what you’re doing. You can then also use the latest firmware, which hasn’t yet been pushed to the cloud, which may, or may not, contain additional features/bug fixes.
@mumblepins was kind enough to create an installer (for windows) that makes it extremely easy to set up the tools you need to get started. Have a look:


#3

What a timewaste!!

OK - here’s how to fix that wretched breathing-magenta annoyance:
Install the toolchain (takes, like, 3 hours…) Toolchain for Windows Installer
Download the firmware: https://github.com/spark/firmware/releases
Put photon into DFU mode (press both buttons, release reset, then release setup when it start flashing yellow)
Install http://zadig.akeo.ie/ and the DFU USB driver: Tutorial: Installing DFU-Driver on Windows [24 Feb 2015]

re-flash everything thusly:-

dfu-util -d 2b04:d006 -a 0 -s 0x8020000 -D system-part1-v0.4.4-rc.2-photon.bin
dfu-util -d 2b04:d006 -a 0 -s 0x8060000:leave -D system-part2-v0.4.4-rc.2-photon.bin
dfu-util -d 2b04:d006 -a 0 -s 0x80E0000 -D tinker-v0.4.4-rc.2-photon.bin
dfu-util -d 2b04:d006 -a 0 -s 0x80A0000 -D tinker-v0.4.4-rc.2-photon.bin

(nb: those last 2 are different)

it will probably still not work, so, re-flash it all a second time:

dfu-util -d 2b04:d006 -a 0 -s 0x8020000 -D system-part1-v0.4.4-rc.2-photon.bin
dfu-util -d 2b04:d006 -a 0 -s 0x8060000:leave -D system-part2-v0.4.4-rc.2-photon.bin
dfu-util -d 2b04:d006 -a 0 -s 0x80E0000 -D tinker-v0.4.4-rc.2-photon.bin
dfu-util -d 2b04:d006 -a 0 -s 0x80A0000 -D tinker-v0.4.4-rc.2-photon.bin

then set it up (might need to press setup for 3secs to get blue flashing):

photon serial wifi

And yay - good to go.

you might also need to fix your path under cmd.exe

PATH=C:\Particle\Toolchain\MinGW;C:\Particle\Toolchain\MinGW\msys\1.0\bin;C:\SparkCorePrograms\dfu;C:\SparkCorePrograms\Git\bin;C:\SparkCorePrograms\GNU Tools ARM Embedded\4.8 2014q2\bin;C:\SparkCorePrograms\GnuWin32\bin;C:\Users\Main\AppData\Roaming\npm;C:\Particle\Toolchain\Make\bin; C:\Particle\Toolchain\GCC-ARM\bin;


#4

Glad to hear you’ve got it working again, sorry it took so much effort. Thank you for sharing your solution! Let me know if you encounter any further issues.


#5

Yeah - worked for about 10 mins, then eventually gives up and sits in fast-cyan without my code running.

If people want to develop in spite of this, I think here’s how (I’m using Serial.begin(230000) which is working fine to see how my project is going absent the wifi right now):

a) put this at the top of your code: SYSTEM_MODE(MANUAL);
b) click the little cloud icon from build.particle.io to download your code to a file (note: you can’t use the network this way)
c) go into DFU (yellow flashing)
d) flash your program: dfu-util -d 2b04:d006 -a 0 -s 0x80A0000 -D [filename].bin
e) hit reset - now it runs (normally, it will not run if wifi fails, and in my case, it always fails after about 30mins or so)

references:
DFU


or https://github.com/spark/firmware/releases

System modes:
https://docs.particle.io/reference/firmware/photon/#system-modes


#6

It’s strange that it still fails. Have you got other Particle devices with similar, or completely different, behavior?

The system modes are a great way to control your connections, and allows you to handle them more catered to your purpose.
To make step D and E a bit easier, you could try the following: particle flash --usb [filename].bin. That should also allow you to flash your application.


#7

Hi @cnd,

Thanks for sharing your findings! As @Moors7 indicated, the breathing magenta state indicates that your photon has an app it wants to run, but the system-modules aren’t up to date enough to run it. You can download and OTA those system parts without installing the full toolchain:

1.) install the CLI and login
2.) grab the photon system parts from here -> https://github.com/spark/firmware/releases
3.) particle flash your_device system-part1.bin
4.) wait for this to finish and for your device to restart
5.) particle flash your_device system-part2.bin

I’m really sorry that things stopped working after an initial good experience. I’d be really curious to learn why things got into a breathing magenta state, were you compiling and flashing locally at the start? Was this just using the Build IDE?

I’m curious to learn more about how you said your device fails after 30 minutes, can you describe the failure case you’re seeing?

If you’re still having issues, or if you think your units are defective, can you email us at hello@particle.io?

Thanks!
David


#8

Hi Dave

If I say “particle list” and nothing shows up “online”, would that not indicate it’s impossible to execute “particle flash your_device system-part1.bin” with any success?

I’ve got 3 “particles”; A, B, and C (that’s the order I unboxed them over a week or two). I flashed LED blinking to A (with a minor mod to make it flash an external LED I added with resistor to D6, as well as internal. I flashed various LED blink and UDP/TCP testing things to B (never attached any electrical stuff), and C was never flashed or connected to anything yet (the above pain all came from “C”, but A and B misbehave as well). After I fixed it above, I flashed the LED blink, and it runs my code (erratically) for a few minutes then dies at flashing cyan (multi reboots don’t change it).

I’ve just powered them all on at once (1st time ever) - I re-flashed C to plain blink (so wifi works again). All 3 connected and worked first time (I don’t think I’ve ever seen them do that before, by the way). I’ll see how long they keep going for today.

I’m wanting to move large amounts of sensor data off these direct to my PC over UDP, as fast as possible; kindoflike a software oscilloscope, by the way.

Thanks for paying such close attention to me! I wish I looked after my own customers as well as you’re looking after me…


#9

OK - C just rebooted for no apparent reason (I would not have noticed, except Windows makes the USB connection noise). It did go back to breathing cyan after that though.

Which reminds me - I noticed in the past that the act of trying to reflash from the online IDE seemed to somehow trigger the reboots (the reflash never actually succeeded - device went weird right away. It didn’t happen with enough regularity for me to be 100% certain that was the cause though)


#10

particle flash your_device system-part1.bin will go over the cloud, so your device would need to have a stable Internet connection. particle flash --usb system-part1.bin however will go, as the command might suggest, over USB. You therefore won’t require an internet connection and can use that when your device is behaving erratically. It’s also much faster :smile:


#11

My devices A and C just both rebooted at the same time (it’s probably irrelevant, but C is plugged in to my PC monitor USB hub and thus my windows PC, A is on a USB battery thing, and B is direct on a mains USB supply)

They each worked fine for about 1 minute, then they both rebooted again just as I’m typing this in.

All 3 are running variations of the “blink” demo (C says “hello” over USB serial as well, A blinks a seconds external LED, and B blinks different speed)

A rebooted once more as I typed the above. It’s been flashing fast green now for about a minute, and is no longer running the blinck code… update… back to breathing cyan and … update… before I even finished typing… jumped into flashing cyan… update breathing … update red … update … basically - it’s a rainbow crashfest.

I worry greatly about the potential damge this might cause - I noticed my external LED stayed on while it was fast-cyaning itself… if that was a cutting laser instead of an LED… yikes!

I think you need to force everyone to create a new bit of code in all of their projects: “safe pause”, so their internet-connected killer robots don’t escape the pen and slice the heads off the children spectators… when your internet malarky needs to interrupt us - call our “pause evil” code first, then when you’re done, call it again with the un-pause flag. Yes, we can control wifi with greater precision I know, but if you’ve never seen it die like me before, you will not even know you have to, or what happens when it does die, so you won’t be looking for that or knowing you should be using it…

fwiw - A crashed a few more times, and C once more (update: now a second time too).


#12

Update: “C” is up and down like a yoyo.
“B” seems happy.
“A” has permanently given up (stable now at fast flashing cyan forever, reprting as “offline” to “particle list”).

I wonder if I just hit “bad luck” and got 2 duds?


#13

Damn. “B” just joined the crashparty. 3 reboots in about 2 mins so far.


#14

Sorry, I don’t have a solution (I don’t have a Photon, either)…but you don’t have to local compile to get a BIN file to flash with DFU Util. In Particle Dev IDE, there are two compile buttons. The top one (looks like an “electrical spark”) requires that you select a device; it goes OTA. The button below it (a circle checkmark) is titled, “Compile and show errors if any”…it actually compiles the project, and puts the resultant BIN in the project folder on your computer. You can DFU-flash that file, saving the frustration of a local build. (I know…I’m living in a local build environment now.)


#15

@WebDust21 - thanks, yeah, the toolchain thing is actually a collection of stuff some guy made which happens to add the dfu-util binary on to your PC an stick it in your path - it’s easier to click “go” and wait 3hrs, than work out how to just make the dfu stuff run in isolation I think. All my photons are now back to being permanently offline, so I’m doing just as you said: download the bin and flashing locally. Works nicely.

I’m going to try them all on a different (3rd) wifi when I get a chance - they fail on both my ADSL wifi, and my phone hotspot, but maybe they’ll start behaving if I have one last try…


#16

Hi @cnd,

Hmm, I wonder if these restarts are just the photons losing the Wifi connection and restarting. I think a recent version of the firmware is a little too eager to reboot if there are connection issues. How’s your Wifi signal strength by your computer? Can you try powering the devices with a different usb cable / power supply, or try an external antenna?

Thanks for the detailed report, I like the “safe_shutdown” idea!

Thanks,
David


#17

Hi,

I’m not sure whether I am posting this in the right place because it’s partly a local cloud issue and partly a ‘breathing magenta issue’, but here goes.

About 3 weeks ago, set up a local cloud on a raspberry pi and connected Photons to it and it works just fine. The firmware is pretty rudimentary - just something to test functions, variables etc. I flashed the firmware onto the Photons when they were connected to the Particle Cloud by using the Particle Build Web IDE and then changing the core keys to make the Photons connect to the local cloud. All good, and everythig worked fine.

Now I want to put some new software onto those local cloud Photons. I wrote the software in the Web IDE as before, selected a Photon that is currently connected to the Particle Cloud as a dummy device and compiled the software. Then I down loaded it, transferred it to the RPi and tried an OTA flash. It went into breathing magenta - permanently.

I thought this was a local cloud issue, so I then connected the Photon and tried to flash it with the same firmware via USB. Same thing.

So, then I took the Photon that is currently connected to the Particle Cloud and flashed the same firmare file to it via USB. It worked fine!

In summary:

1 I can compile with the Web IDE and either OTA or USB flash a Particle Cloud connected device with no problem.

2 If I take the same firmware file and flash it to a local cloud connected Photon I get permanent breathing magenta.

A couple of other notes:

a all the Photon have the latest release
b when i flash tinker to any of them they work

Any ideas? It’s not really practical for me to move a Phton to the Particle Cloud to flash it, then swap it back to the local cloud. Not least because I have another Photon on another RPi server about 500 miles away!

Many thanks,

R


#20

Having read through this thread again (esp Moors7’s note of August 8) I think I have solved the problem. I thought I had flashed the latest system firmware 0.4.6 but when I flashed this again the user firmware seemed to flash ok Everything seems to be back to breathing cyan.

.