Photon hard fault, even on Tinker

Troubleshooting
#1

Hi,

my Photon suddenly seems to have died. After running weeks without any issues and
controlling my heating it ends in endless loops of sending SOS and a red light which
signifies a hard fault. I’ve took it out and plugged it into the computer.

I then put it in DFU mode and ran particle update which worked, but
still get a hard fault while it’s connected solely to my computer.

I tried to put it in Safe Mode, but it just started SOS’ing again.
I’ve performed a hard reset (10s+ & flashing V0.4.9 firmware via USB), downloaded
Tinker to it, but it still returns a hard fault error.

I tried that yesterday several times (in addition to particle update).
It flashes successfully, but reboots and goes back to flashing SOS + hard fault.

So, hopefully anybody can help me. Is there a way to clear the DCT?
(I’m using Mac OS X 10.11.3 and current Particle-cli.)

Kind Regards,
Marcus

PS: The replaced new photon works fine with the same firmware for over 2d now.

Hard Fault on Custom PCB
#2

Before we erase the DCT it would be good to get a copy, so we can diagnose the fault.

Please run

dfu-util -d 2b04:d006 -a 0 -s 0x8004000:0x8000 -U dct_sos.bin

then send me a PM where I can find the file for download, and I’ll try it to see if it’s specifically a problem with the DCT.

Erasing the DCT can only be done with a programmer shield at present. Do you have a programmer shield?

#3

Did my PM reached You?

Regards,
Marcus

#4

Mat is likely sleeping now :slight_smile: You can PM the same thing to me if you’d like to. I have some steps you can try as well that I’ll share via PM.

#5

I came here to ask for help, I was going to start a new thread, but I think I’m experiencing this exact same issue, so I figured I’ll pile onto this one.

I can put it into DFU mode and flash over USB (which appears to work) but it just goes back to SOS mode after that. I tried it with the standard arduino blink example among other things. (The SOS mode gives me 1 red blink after the SOS pattern).

I can’t boot into safe mode - it will blink magenta while I’m still holding down Reset, but as soon as I let go, it goes back to SOS mode. (Unless I hold it down log enough for DFU mode, of course)

Sent my file via PM…

Also, I don’t have a programmer shield… Any chance I could fake it with an arduino or whatnot?

#6

@MaxSharx @nfriedly I checked out your DCT images and they look ok. Would you both please send me your full binary images via PM? Here is the command:

dfu-util -d 2b04:d006 -a 0 -s 0x8000000:0x100000 -U photon_backup.bin

If your bootloaders are fine we can get you back to normal without a programmer shield.

#7

@nfriedly for you, it appears one of your system parts was corrupted. This can happen if you interrupt the power or USB connection while running a particle update. You can easily restore by putting your Photon in DFU mode and running:

particle flash --usb tinker

put in DFU mode again

particle update

#8

Thanks @BDub, that did the trick!

I’m not sure exactly how it got corrupted, I had it on battery before, so maybe that killed it, although I could have sworn I had it working since then. Oh well. Glad to have it working again. Thanks for the help!

1 Like
#9

From my side, unfortunately without success:

> $ particle flash --usb tinker
> running dfu-util -l
> 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!!!
> Deducing device DFU version from functional descriptor length
> 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
> Flash success!
> $ particle update
>Your device is ready for a system update.
>This process should take about 30 seconds. Here goes!
> ! System firmware update successfully completed!
>Your device should now restart automatically.
>You may need to re-flash your application to the device.
> $

Maybe something can be found in the image.

TIA,
Marcus

#10

Hey Marcus,

So for you… your image boots fine for me. I just had to add WiFi credentials and update the keys and it connected. I have heard of a hardware issue causing an SOS as well. I’d be curious to know what kind of things you have hooked to your Photon… and maybe keep the second photon you have from suffering the same fate.

I’ll PM you with steps to reset your DCT just in case that’s the real issue.

#11

Hey Brett,

I deploy a Photon, a ShieldShield V3, and an Arduino Grove shield to control my heating.
Movements, noise, light, temperature, and other status information are used to optimize the heating cycles – like NEST. Actually, it looks more like a bomb than a NEST thermostat. :blush: But V2 with a touch display is in preparation.

IMG_0404.JPG3024×4032 2.14 MB

It has been working for weeks …

#12

Wow that’s a lot of gear there! So from PM we determined that you don’t have a DCT issue… could have been a hardware failure. Let me noodle on this and think about why this could have failed… also, that’s not a piece of styrofoam behind the unit right? A white pillar of some sort?

#13

Here you can see the V2 prototype. Currently, I’ve trouble with the touch controller. But that’s another story … :wink:

IMG_0407.JPG4032×3024 1.88 MB

#14

That “device” replaced my old thermostat and sits near the door on a massive wall of my office. Inside the small grey box the relay resides to separate high and low currents. Furthermore, it protects the rest of my family of accidentally touch any high voltages parts. But, my children fear that thing anyway. :smile:

Regards,
Marcus

#15

:bulb: moment here… I remembered that in some rare cases the Shield Shield can oscillate with long wires.

The Shield Shield which is meant to be used to convert 3.3V to 5V and to give you an adapter for the arduino shield form factor. This works great with Arduino shields because their connections are short. Because the level shifters on the Shield Shield are automatically switching bi-directionally, they do not like any added capacitance or increased load applied to them. If you use them for anything other than a light load, or if you attach light loads on long wires, they will tend to oscillate at 50MHz back and fourth between INPUT and OUTPUT mode. This could have possibly been a reason why your Photon has suffered failure but it’s unclear exactly why. I’ve had various peripherals not work before with the Shield Shield because I used long wires… but never had my Photon SOS into hard fault permanently because of it.

You might want to consider one of these if you don’t actually need the 3.3V to 5V level shifting for your sensors.

Does it register lots of multiple taps when you touch it? I remember using these and needing to calibrate the size, and also used the Z axis (force) value in a debounce routine to keep the multiple touches from being a problem.

Oh! I can read “Couldn’t start the touchscreen controller” that’s fancy and I have no idea how that particular one works :wink:

#16

Hi,

hmm the longest wire is 50cm and the rest only 20cm. More likely, the analogous inputs are the cause because of a bad voltage level (maybe peaks or a little bit too high sometimes).

The controller and the display uses both the SPI and interfere, i.e. one of them can’t be initialized. But, there is another thread belonging to this issue.

And the ShieldShield isn’t really me friend either. And there is an thread for it, too. :smile:

Regards,
Marcus