Is it just me, or is there now a problem flashing from the Web IDE?
{“data”:“panic, hard_fault”,“ttl”:60,“published_at”:“2017-06-08T07:49:12.738Z”,"",“name”:“spark/device/last_reset”}
@mattmcd1 is that device locally in reach?
Sadly, no.
That error is code related and not flashing issue. Is your device online?
Yes. It is online and running the code that was last flashed to it (i know this as it is logging to Papertrail every second). i can’t flash new firmware to it. From what i can see, it is having trouble connecting to the cloud (console.particle.io shows this panic, hard_fault every 30s or so - as does my Papertrail log)
It means that the device is getting a hard_fault which caused it to restart.
The code probably has some bug, causing this behavior.
If only i could flash back to a stable state…
Can you share the code with me privately?
I would like to see what’s going on for learning on what’s causing the hard fault 
Whilst i don’t know why the Photon was resetting, it seems that the problems that i’m having flashing the device are a result of this constant resetting. If i try enough times from the Web IDE, it will eventually say “Flash successful”. I have just flashed the Tinker app from the Web IDE and had it report that it was successfully flashed. Unfortunately the photon is still running the old code! (logs still being written to Papertrail).
The code is not easy to share… multiple files.
You could use the "share this revision" functionality to share a snapshot of your entire code 
(If you're using the Web IDE)
Problem found… unfortunately no solution found.
Whenever i try and use the Logging class to make a log entry (using the Papertrail log handler) from a Timer callback, everything dies (to be clear, by “dies” i mean the Photon starts getting hard faults and resetting itself).
PapertrailLogHandler papertailHandler("logsX.papertrailapp.com", xxxxx, "BeerFridge");
void setHeatingMode()
{
Log.warn("Controller mode changed: HEATING_MODE");
...
}
Timer heatingModeTimer(10000, setHeatingMode);
void setup() {
...
heatingModeTimer.start();
}Timers are essentially interrupts, and thus should be kept as short as possible. Long running processes, especially networked ones, can mess things up. Try setting a ‘flag’ in the timer, and check that during the loop().
From the documentation:
The timer callback is similar to an interrupt - it shouldn't block. However, it is less restrictive than an interrupt. If the code does block, the system will not crash - the only consequence is that other software timers that should have triggered will be delayed until the blocking timer callback function returns.
It’s one of the edge case that we have to dig deeper into to figure out what’s causing the panic.
The Log class might not be accessible as a callback via the Timer function etc.
The firmware gurus should have more insights when they rise and shine 
You can quote the docs, but you should also try the advice you get.
And the ellipse in your code excerpt might also disguise the actual cause.
But probably the implementation of the PaperTrail logger might feature some “toxic” code for the use in Software Timers.
What happens if you use a SerialLogHanlder instead?
One other thing to consider is, that Software Timers run on a thread with rather limited stack. So a “lot” (actually not too many) of nested function calls proof toxic there too.
3 Likes