Ok, so I was having the same issue with the solid green light, and got it working after a couple hours of tinkering, countless resets and attempts at flashing new firmware, and cycling through the full rainbow.
Last [known] steps I took:
factory reset (back to blinking blue)
used the mobile app to setup wifi (particle-cli did not work, even when it seemed to succeed. After restart, the device would just blink green)
went to the Build UI, flashed tinker
in the app, it still said ‘online, non-tinker’. I pressed the flash button and flashed tinker again
After this, it seems to have tinker installed and it works with the mobile app.
Build still says I’m on SPARK FIRMWARE V0.3.4. Trying to flash a more recent version (v0.4.4) gives me this:
Found DFU device 2b04:d006
running dfu-util -d 2b04:d006 -a 0 -i 0 -s 0x080A0000:leave -D /Users/rtomasi/Downloads/system-part1-v0.4.4-rc.2-photon.bin
Error writing firmware...Error: Command failed: dfu-util: Invalid DFU suffix signature
dfu-util: A valid DFU suffix will be required in a future dfu-util release!!!
dfu-util: Error during download get_status
Is there a way to trigger a firmware upgrade via the web UI?
After unsuccessful WiFi connectivity attempts using both the Android, and then iPhone, apps I defaulted back to the Windows based USB process using CLI.
My symptoms are exactly the same as my fellow experimenter above;
“Also have a single Photon…that is in the SOLID GREEN state. Same issues as described in prior posts: solid green, but can enter flashing yellow DFU mode…Cycling through the modes to flashing white (factory reset), but release at this point just returns to solid green.”
Looking at a solid green LED, with no access to safe mode (just returns to solid green once the setup key is released while the indicator LED is flashing magenta) is very frustrating (especially considering the long lead time from order to delivery).
Please Particle, can I\we be provided a resolution to this issue?
I had the same problem today with one of my Photons (new setup), just goes to green. I put it in DFU mode and flashed the latest firmware 0.4.4 and it’s working fine now.
I received two photons yesterday and both are not working correctly. I did finally get one to connect to the cloud and register but after it did the over-the-air update it went to the solid green mode. Here is my memory dump:
I did upgrade the firmware to 0.4.3 through the DFU-Util to make sure it wasn’t that but I’m still having difficulties.
I also have an Atmel Dragon Programmer/JTAG but will order something different if I need to.
If you’ve got the CLI installed, could you plug it in, set it to DFU mode, and issue a particle update? That should upgrade it to the latest version (0.4.3 isn’t the lastest anymore ;))
Done, I did “particle update” while in dfu mode “yellow”. It seems to have update as it flashed once and then reset, immediately after resetting it switched to an almost solid green. If I hold down the setup light it will go through the debugging modes of magenta->yellow
If I let go when the color is magenta, the photon will go white and then start blinking blue. However, when I start the particle setup using my phone. The network showed up in my settings, it got found in the app, started the setup, I entered the network password, started the next part of the process but the photon kept blinking blue without continuing.
dfu-util: A valid DFU suffix will be required in a future dfu-util release!!!
Opening DFU capable USB device...
ID 2b04:d006
Run-time device DFU version 011a
Claiming USB DFU Interface...
Setting Alternate Setting #0 ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 011a
Device returned transfer size 4096
DfuSe interface name: "Internal Flash "
Downloading to address = 0x080a0000, size = 3952
Download [=========================] 100% 3952 bytes
Download done.
File downloaded successfully
dfu-util: Error during download get_status
Error writing firmware...dfu-util: Invalid DFU suffix signature
dfu-util:
A valid DFU suffix will be required in a future dfu-util release!!!
dfu-util: Error during download get_status
However, I just reset and started “breathing cyan”, and I can connect to it through the iPhone app.
Hope my export helps. Now to try and get my other one working.
Hi all.
Same problem stated by @casm.
Just bought one Photon + programmer but I’m really regretting this buy.
It seems like a nice hw, but everything else is a nigtmare… so, I don’t even want to use the programmer shield with the Photon if I don’t know if the photon is ok.
I’ve tried every possible solution posted around the web with no luck.
At least the programmer is going to be an useful jtag (I really hope the programmer works… $92.38 on a FT2232 JTAG… not very nice… yes, 92.38 include shipping to my 4ºth world country).
Anyone know where i can request a replacement? or complain directly?
If you've got the CLI installed, could you please try the following:
Plug your photon in, and place it in DFU mode.
Issue particle update from the CLI.
Once that is done, place it in DFU mode once more
Run particle flash --usb tinker
it should now be in listening mode (blinking blue)
issue 'particle setup serial' and follow the steps
Let me know how/if that worked for you?
As far as contacting Particle goes, you could mail to hello(at)particle.io, although most employees are on the forums, and answer within a day (mostly).
Hi @Rola! If you have a programmer shield, then you have everything you need to be able to fix your photon, if it’s become stuck. I’m sorry if your experiences so far have been frustrating, but please be assured that since you have a programmer, you will be able to get out of any problems. Please let us know specifically the issues you’re facing and we’ll get you up and running.
nightmare for me: compiling, installing a ton of sw just to flash it (linux), cloud needed for almost everything, serial commands almost useless (why bother to have it if not implemented properly), try to make the most simple “getting started” and failed hehe.
I did your recommendations (allready done that but I did it again =D), besides flashing directly the system1, 2 and tinker (vers 4.3 and 4.4) -> same result as stated earlier: when pressing the mode button it waits about 30 seconds with the led on the last state before entering the listening mode (solid green or off), and then the blue led start to flash.
configured a wifi connection trough serial (not cli) (just ‘i’, ‘w’, and ‘m’ “commands”??? really???)-> led blinking green (trying to connect to wifi) but even next to the AP there’s no connection.
with the “particle setup serial” i can get to the part that it ask me to change to the photon network wich never connects to it… Wait!! I have the photon connected trough USB… WHY, just WHY not using it. Why switching network is needed at all… it even recognize it and asked me if it should use the USB: YES!!.. aaaaand nope… it doesn’t use it… hehe… funny isn’t it?
With the “particle” app on android it’s the same behaviour stated above: “Connecting to Photon” eternally, kill the app is the only thing that allows you to retry.
Mdma:
hardware problems are not solved by a programmer, but thanks anyway.
Is there a diagnostic firmware that we can upload to the photon?
Can you, please, make a serial communication usefull?
Can you make the local upload firmware more simple? Like mbed… I own the mbed lpc1768 and it’s VERY usefull, online and offline (eclipse/gcc-arm/openOCD)
Errors on the dfu-util should be solved.
@YetiWilson said that his Photon whas getting really hot, mine too. Which could mean faulty hw.
I do have access to a reflow oven: Photon to the Oven… hoping it will survive and work (due to monday and will post the results).
That depends largely on how you'd like to flash it. There are tools available for pretty much every level of complexity. The web IDE is by far the easiest, albeit pretty limited. Then you've got the option of using Particle Dev, which is a bit more user friendly. Next up is the CLI, which you can use to flash your .bin files (downloaded from the Web IDE, retrieved from Particle Dev, or compiled locally). Then there's local compile, where you have access to pretty much everything. The complexity of compiling locally is greater, but if you're willing to go down that road, I think it's fair to expect one to the able to install the necessary tools.
In all honesty, it is a 'cloud connected device'... That said... you don't have to use it. It's there, but it can just as easily be disabled. Run the thing in manual mode, and you're in control of the connections.
Not sure on that one. What commands would you like it to have, and what is currently 'not implemented properly'?
That's indeed a strange one, which I'll pass on. Then again, we've got particle serial wifi and particle setup wifi which should both work over serial. Give those a try?
Considering you're able to flash it, and it's able to 'play' different LED colors, I doubt it's a hardware issue.
Any specific things you think should be implemented. "Making it simpler" is a rather broad statement, which is hard to interpret. Functionalities in tools, different tools, modification of tools, something like that?
If it's this error: dfu-util: Error during download get_status, then I'm afraid that's not on Particle:
If you're willing to try and debug issues here before frying it, you might have a better chance at finding the issue. The folks at Particle are very helpful if I may say so.
What configuration is your router in? What type of network, 2.4/5GHz, a/b/g/n/ac, channel? Perhaps two networks 2.4/5 broadcasting under the same SSID? If so, try changing one, or temporarily disable 5GHz.
Flashing: All the options that falls down to install things to flash it in my current state and OS (cli, dfu)
Cloud: so, i have to make an app to test in manual mode even if I can’t test the simplest thing. With that I will have 2 doubts instead of the important one: is the photon OK? and that’s the real question here.
Serial: well, the simplest things that comes to me in mind is search for wifi networks, list credentials, see what’s on the flash, see the app name, initialization error mesages, etc, etc…
Commands: same result, it’s the same of w command on serial port.
hardware: Been able to do some things doesn’t mean that it’s all ok.
upload firmware: example again: mbed. but is rather useless if the Photon is OK… again: Is the photon OK?
Dfu: If I use the dfu util I MUST implement all the proper functionality of the tool I’m willing to use. But, ok that’s my point of view in development. (maybe it’s a stm32 boot loader not a fw bootloader, in that case nothing to do)
Oven: Frying it? may I ask what method is being used to assemble the photons? I pretty sure its a reflow work (I might be wrong) and I know putting it twice in there might (just might) cause problems. Anyways I’m going to do that test anyways, if you could provide me a sugested reflow curve I would be pleased to follow it on every second/tº pair.
router: Tested on 2 routers, 2.4, abg, ch6, wpa2… anyway, blinking blue -> not passing trough AP/router -> trying to connect to the photon’s nw -> no connection either as stated before (app&pc).
I am willing to debug, but until now all has been the “try” part.
I will not emit another though because it causes useless discussions.
address the first problem “Why when I press the setup button it takes about 30 seconds to enter listening mode?”. (trying to initialize something and it fails?-> missing configs, lines unconnected due to cold solder, not response form some components, etc)
Any directions?
Or, again, It would be much simple for the people having issues to get a test firmware form the Particle dev board, like the test firmware of production? I doubt that the test fw is the tinker app. I know maybe it’s not intended to be public, but maybe it helps to those with the problem.
Edit2: around here is the problem (I think) I stoped it 4 times in the 30 seconds transition from normal to listen, all of them ~4 seconds apart and allways stoped here:
- Program received signal SIGINT, Interrupt.
- 0x08070736 in network_connect (network=2779096485, flags=536968528, param=2779096485, reserved=<optimized out>) at src/system_network.cpp:257
- 257 if (!network_ready(network, flags, reserved) && !WLAN_CONNECTING && !network_listening(network, flags, NULL))
- (gdb) bt
- #0 0x08070736 in network_connect (network=2779096485, flags=536968528, param=2779096485, reserved=<optimized out>) at src/system_network.cpp:257
- #1 0x20002c74 in ?? ()
- Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(First time using the gdb + jtag on command line. Tryed to use tui but I can’t make a step on the code)
So: As the name sais: “task idle” humm… RTOS? (searching…) oh, freeRTOS… never used an RTOS. So I asume that some process or function is getting stalled and the OS waits for it to continue? what happens if it doesn’t? can it kill it by timeout? does that timeout ~ 30 sec?
Well, that’s it for this week I think. I will postpose the oven to next monday.
Edit 3:
Reflow oven didn’t work either.
Result: worst purchase of all time. Too bussy to waste time on this.
I’ve contacted the Spark team (hello@particle.io) about the problem. They’ve sent me a new Photon and it’s working OK. I saw the leds status that it is connected to the wifi network.
About the problem of the other Photon I still don’t know what’s bad about it. So I recommend the same procedure for the people having the same issue (@casm)
