Re: "RESET"

On 5/25/2025 2:19 AM, Martin Brown wrote:

On 24/05/2025 23:34, Don Y wrote:

I don't quite understand the need for "reset" buttons on products.

 There are things like routers and mobile phones where there is a very significant difference between power on/off and a hard factory reset. The former recovers it form having crashed internally whilst the latter trashes all previous settings into oblivion.

Yes, but (as stated elsewhere), that is part of the UI.  Software *interprets*
it.  And, can ignore it if the device model says it SHOULD ignore it at
this point in time.

That function is always available by cycling power -- even for devices
where that is difficult for the user (e.g., PoE, BBU, etc.)

 Not always available - there are quite a few different levels of reset too. I recall one particularly annoying one on an early Android device that require holding the on/off button and volume down in for 4 minutes. It did do a hard factory reset on about the fifth attempt. The previous four having failed because my fingers slipped. One minor annoyance was that the very hard reset put it into Chinese language mode.
 ISTR the ordinary soft factory reset was about 10s holding the magic buttons in (but didn't work on this unit).

But those are user interface functions.
PCs have *hardware* that implements the "4 second power off" (regardless of
state of CPU).  It's part of the SuperIO.  I.e., a *real* RESET that doesn't
require the cooperation of the CPU.  An acknowledgement that the CPU can go
south and not recover.

Shouldn't a device be able to get itself out of a "pickle" without
requiring the user to intervene?  Particularly devices that are
intended to "run forever"?

 In an ideal world yes. But I have seen such devices in a state where the only process still running was the one pressing the dead man's handle to say that everything is OK. Many routers tend to go haywire after a continuous uptime of about 2 or 3 months having fragmented their stack.

That's a poor design.  The thing that strokes the watchdog mechanism
should, itself, be reliant on proper operation of the rest of the device.
I've seen designs where a timer started a process that stroked the
watchdog and then slept awaiting the next timer invocation.  Clearly
not doing what it was intended to do as damn near everything in the machine
can be hosed and that process still functioning properly.
The epitome of this is "let's set up an interrupt that will stroke
the watchdog FOR us!  That way, we won't have to worry about being
too busy to get around to doing it in a timely manner!"
Such interfaces shouldn't be purely "time" based.  I always use a second
(dirt cheap, small package) MCU to act as a reset controller.  It "talks"
with an application in the main processor so *it* can exercise some
judgement as to whether or not the main processor is "sane".  It can
also hinder counterfeiting as one can usually get a small, "secure" MCU
whereas trying to "secure" a larger device becomes difficult (e.g., the
memory and busses can easily be monitored)
It controls the RESET signal as well as the RESETIO signals so *it* can
bring the field to a safe state even if the main processor is completely
hosed.

I.e., it seems like the presence of a reset button is a tacit admission
that the engineering is "lacking"...

 It could also be to reset to a known state. Several of the more annoying gadgets have one time programmability from a PC but to make them secure the moment you make them active all further communication is impossible.

That's often to discourage hacking.

The only way to reprogram is factory reset and start again from scratch. User interface designed by someone who really enjoyed the maze in Zork.
(some TV tuning menus fall into this category)