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