2 ms·

I think the issue is that sort of behavior requires coherence it may not have and can fail if say its stacks are stuck in infinite loops. That approach seems a

I think the issue is that sort of behavior requires coherence it may not have and can fail if say its stacks are stuck in infinite loops. That approach seems a bit more like a "launch options" than a "reset" function. A reset signal on the chip level essentially needs to takes priority over all other processes - since if they aren't responding to requests from entering undefined behavior it will never hand over. Then once reset is achieved it restores it to a base state - implying either a default state like say all 0s or all 1s works without any logic (probably not for internet of things) or it loads over a default state from a ROM.

kstenerud 7y ago
The way I see it, if they're able to trigger a reset routine from a series of on-off signals, they can trigger any code path from it. A base configuration wipe or code overwrite could just as easily be a call to a separate code process/stack that runs completely isolated from all configuration values and supports the primitive commands that you'd need anyway to configure the device to a deterministic state for your use case, or update the firmware, etc. If you're able to configure the device in the first place, you're able to trigger it again since nothing on that code path ever changes, has persistent state, or reads configuration values.