Developers using OTA update to program the core sometimes have to perform a factory reset in order to regain cloud connectivity - for example, after flashing firmware that starts in semi automatic mode and, due to a bug, doesn't enable the cloud.
Factory reset resets everything, requiring users to re-register wifi credentials. Developers who have dfu-util and the spark CLI installed can use that to reflash the stock tinker app to regain cloud connectivity, but these tools are not available out of the box, and must be installed.
I'm thinking of a "safe-mode" - where factory code is restored without resetting the wifi credentials - would help speed up the development cycle.
This could be achieved by a longer press of mode on startup, longer than used to enter DFU mode, but not so long to cause a full factory reset. The mode hold duration, LED colors and actions would be like this:
< 3 seconds: boot normally
3 seconds, flashing yellow, DFU mode
6.5 seconds, flashing green, safe mode
10 seconds, flashing white, factory reset
The new thing is the flashing green at 6.5 seconds. Letting go of mode when you see flashing green would restore the factory firmware without clearing wifi credentials.
@mdma, I like the OTA safe mode to avoid the whole factory reset/wifi/reclaim yada yada thing. Makes total sense.
I need clarification on the panic events. Am I correct to say that all panic events end in a stall (flashing LED and nothing else)? It would be great to combine @AndyW’s reset syndrome concept with the panic events to determine the best course of action like going to the OTA safe mode or reloading the factory Tinker for example. In fact, when I think about it, loading factory Tinker IS a safe OTA mode!!! Just thinking out loud
Yes, at present panic events don’t save any state about the panic. With backup registers, we could save the cause of the panic as well as other state that might be needed by the bootloader to determine the best course of action.
I do agree - there should be a “hands-off” way to do this ideally, but keeping in mind that automated things can also end up kicking in when you don’t want them to, so it’s a fine line to tread.
So, initially, just taking the first steps towards a manual approach, until we have more details persisted to support analysing causes of reset and automatically selecting the appropriate boot action.
@mtnscott, I have to apologize. The discussion @AndyW created was for Elites and brought up the idea of being able to manage the Core’s behaviour after a reset based on what caused that reset (sleep, panic, etc.). At this point, it is only a bantering of ideas.
It might be cool if tinker was loaded automatically AND was expanded to include a display with debug information. This might make the developer’s iteration cycle shorter.
I like the idea of a recovery mode since I experienced this issue a number of times, rather annoying to keep reentering your WiFi credentials
Sidequestion, would it also be possible to enter DFU mode without pressing the buttons on the core (and perhaps adding some code)? Handy when you are not around your core
There's the function System.bootloader() (that's presently being documented) that will reboot the core to dfu mode, so you could trigger that remotely via a function.
For the photon we are looking at ways to avoid dfu mode altogether so that images can be flashed to the device without pressing buttons.
That's a nice idea, but the system can only reset to whatever is in the factory firmware. On the photon, the system and user firmware are completely separated meaning we can potentially do more.
What kind of debug information would you like to see displayed? (I'm guessing you mean displayed via USB Serial?)
As for debug information, I was thinking that kernel panic info such that @peekay123 was alluding to would be nice. I’m sure there is a bunch of other debug metrics for the CPU that would be helpful. I was not thinking of sending this via USB, rather sending in over the air to the iphone app.
It's the default factory firmware but users are free to change that. So Tinker to me specifically means the tinker app, which might not be what's in factory firmware - hope that makes sense!
Ahh, got it. So the debug idea isn’t really applicable. But the “safe mode” you mentioned would be great to wipe the user firmware without wiping the wifi credentials.
how about rather than event based on how long the long hold is, you did this: long press and hold mode, then tap the other button multiple time for various events.
The other button is reset, so when you tap that the system resets.
However, I like the idea of entering a “selection mode”. This could be the case if you release the mode in under 3s. Then taps of the mode button cycle through different selected modes - the mode is indicated by the color of the LED, yellow for DFU, green for safe mode, white for factory reset, and cyan for normal boot. The mode takes affect when you hit reset.
