Photon Unresponsive, Solid Green Light

If it’s breathing cyan, and you can connect to it, I’d say it’s working. The DFU error is a known issue, nothing to worry about.

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?

Could you define:

What is the current state your photon is in?

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.

Hi @Moors7 and @mdma, Thank you for your time.

Moors7:

  • 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).

Thank again.
Rola.

Let me try and address some of your concerns.

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.

Okok:.

  • 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.

Let’s debug =D:

  • got eclipse, programmer, firmware (form git), gcc-arm, anything else?
  • 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.

Well, Have a nice day.

Rola.

Edit:

  • I think it’s a fw boot, not the stm32boot.

  • Nice steps for Programmer shield: https://medium.com/@jvanier/5-steps-to-setup-and-use-a-debugger-with-the-particle-photon-ad0e0fb43a34
    -Some info

    #- > flash info 0

    0 : stm32f2x at 0x08000000, size 0x00100000, buswidth 0, chipwidth 0

    0: 0x00000000 (0x4000 16kB) not protected

    1: 0x00004000 (0x4000 16kB) not protected

    2: 0x00008000 (0x4000 16kB) not protected

    3: 0x0000c000 (0x4000 16kB) not protected

    4: 0x00010000 (0x10000 64kB) not protected

    5: 0x00020000 (0x20000 128kB) protected

    6: 0x00040000 (0x20000 128kB) protected

    7: 0x00060000 (0x20000 128kB) protected

    8: 0x00080000 (0x20000 128kB) protected

    9: 0x000a0000 (0x20000 128kB) not protected

    10: 0x000c0000 (0x20000 128kB) not protected

    11: 0x000e0000 (0x20000 128kB) not protected

STM32F2xx - Rev: X

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?)

si command go trough 0x08070738 and 0x08070736:

08070730 <prvIdleTask>:
  8070730:    b508          push    {r3, lr}
  8070732:    4c03          ldr    r4, [pc, #12]    ; (8070740 <prvIdleTask+0x10>)
  8070734:    6823          ldr    r3, [r4, #0]
  8070736:    2b01          cmp    r3, #1
  8070738:    d9fd          bls.n    8070736 <prvIdleTask+0x6>
  807073a:    f000 fe2d     bl    8071398 <vPortYield>
  807073e:    e7f9          b.n    8070734 <prvIdleTask+0x4>
  8070740:    20017d50     .word    0x20017d50

(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.

Bye all.

Me again.

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)

Bye all.

If you have the other photon, I suggest erasing the DCT pages at locations 0x8004000 and 0x8008000 using your jtag programmer.

After that you’ll have to reflash the server key to the device. (See step 2 here.) Photon setup flashing cyan with a “quick red burst” (now orange burst) [Solved]

Hi Mdma

I am getting the same solid green light. Are we returning the affected units as a solution now? I am a noob so will have some difficulty with some of the advanced solutions on this thread.

Please let me know.

Are you able to enter safe mode?

It is blinking something this time although I am not sure what color. I am slightly color blind. I had tried that before but went back to solid green. It is still showing as offline on my iOS device.

I do know it is either green, orange or yellow if that helps.

Here’s something else to try - if you hold the setup button for 3-5 seconds, it should start blinking blue. One way to verify this without knowing the color is to see if your computer/phone can find the Photon’s SoftAP network. It will be named like Photon-ABCD.

When I press the setup button while the current color light flashes nothing happens.
If I unplug the device and plug it back in it goes back to solid green. when I then push the setup button it does blink in what could be blue for 1.5 seconds or so and then goes back to a blinking yellow, orange, green that we had before.

the photon’s soft network doesn’t show up on my phone

Well - I think I’ve tried what I can here (it is getting to be a long thread)

Absolutely the same symptom of steady green

Tried:

from: https://github.com/spark/firmware/releases
4938 [2015-10-02 18:04:54 -0700] dfu-util -d 2b04:d006 -a 0 -s 0x8020000 -D system-part1-0.4.6-photon.bin
4939 [2015-10-02 18:05:13 -0700] dfu-util -d 2b04:d006 -a 0 -s 0x8060000:leave -D system-part2-0.4.6-photon.bin

Part 1 seems fine , then part 2 I get:

dfu-util: Invalid DFU suffix signature
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 = 0x08060000, size = 168048
Download	[=========================] 100%       168048 bytes
Download done.
File downloaded successfully
dfu-util: Error during download get_status

Goes right back to solid green

When I try the CLI - part 1 again “fine”

4945 [2015-10-02 18:12:34 -0700] particle update

System firmware update successfully completed!

But ends with “solid green” state

4946 [2015-10-02 18:13:30 -0700] particle flash --usb tinker

$ particle flash --usb tinker
Found DFU device 2b04:d006
checking file  /usr/local/lib/node_modules/particle-cli/binaries/photon_tinker.bin
spawning dfu-util -d 2b04:d006 -a 0 -i 0 -s 0x080A0000:leave -D /usr/local/lib/node_modules/particle-cli/binaries/photon_tinker.bin
dfu-util 0.8

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2014 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to dfu-util@lists.gnumonks.org

dfu-util: Invalid DFU suffix signature
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

Back to solid green

As one of the fixes in 0.4.6 dealt with an issue where WiFi credentials got corrupted under some circumstances when there were more than two sets of WiFi settings stored, you could try to clear the credentials by press and holding SETUP till you get rapid flashing blue.
After this reenter your credentials.

No promises, but worth a try - worked for me and some other member.

I am having a similar problem. I have a solid green light after reset and no other conditions. I can enter DFU mode and have updated the firmware to 0.4.6 but the Photon rest with the solid green light. Is there another remedy to try.

Thanks, Jim

Hi @mdma,

I was able to connect photon to WIFI network… The device went into offline mode and it started flashing magenta… after restarting it got stuck to Solid Green Color.

Please help me in solving this issue.

Link for memory log:
https://drive.google.com/file/d/0B5X_2bGbxX4Fd2JRbDFfSHhPSEk/view?usp=sharing