Hardware reset?

[BobC]

On my ESP-01 running the current AT firmware, the AT+RST command can corrupt flash, so a hardware reset is the way to go.   Since I'm certain the Acorn will be using the Espressif library (possibly without the AT command code), it seems possible the Acorn could inherit this problem, so it should also have an accessible hardware reset.

1. Will the Oak board include a hardware reset button?

2. Will it be possible to do a true hardware reset of the Acorn from software?  (Such as by connecting Reset to a GPIO.)

I'd like to avoid having to add external components just to get the module to reset correctly.

[BobC]

Over in the KS comments, Eric said:

We are not using the AT firmware, we are using a custom firmware, so the reliability of our reset mechanism is in no way related and cannot corrupt the firmware. The board does not have a reset button, the reset pin is broken out, the board can be reset from the cloud, IDE, api or by external button.

Still, I assume you are using the Espressif SDK, which includes the low-level library the AT command code calls to do a reset.  I just want to be sure there is NO CHANCE the Espressif reset code will be trusted until and unless it has been validated.

1. Is the Acorn reset code unrelated to the Espressif SDK?

2. Is the software reset mechanism precisely equivalent to a hardware reset?  Or will a hardware reset still be needed?

I've built way too many systems where the EE folks felt a bullet-proof hardware reset was unnecessary, until I proved I could create tests that could completely lock up the system, and even corrupt the on-chip watchdog timer.

Of course, this was while testing under rather extreme conditions, in one case under a vacuum while in the beam-line of a heavy-ion accelerator at Brookhaven National Labs.  And, yes, my code had to keep running until the silicon itself become radioactive.  For another system, the tests required it keep running (or recover quickly) while being repeatedly struck by lightning.  The world can get very nasty to electronics!

Ideally, the software reset mechanism should be precisely equivalent, at the hardware level, to cycling power.  I've built systems where the reset mechanism was indeed a one-shot to a mosfet between the processor and VCC.

When an autonomous sensor is on its own, far away from a human who can press its reset button, if it can't reliably reset itself it will essentially be dead until someone visits it.  A robust reset capability at least allows for the possibility of remote troubleshooting and update.

[digistump]

Our reset method jumps to our bootloader, which then jumps to the correct application. The bootloader holds two applications at any time - the current and the last one, so that if corruption occurs during an upload it will just fail and jump back to the last good and connect back to retry. If at any time both sections of flash failed then the watchdog will jump it to a loop where it watches for a new upload.

I certainly won't claim the Oak will hold up to that extreme of testing!

But our soft reset has proven robust enough in our testing. There is also a Reset pin and a Chip Enable pin - tying an onboard pin to either will allow you to do a remote hardware reset (there is a solder jumper to connect P10 to it even). Since the Oak is a development board we don't try to make something that can be placed on antartica out of the box - that's up to the user, and there are many ways to achieve it.

The reason we leave the reset button off is because it is easy to add one for those who want a hardware reset button, but most don't, so its not worth the cost to put it on board - since the little button would be the second most expensive component if we included it.

[defragster]

To maximize available code/data upload space every other upload could be a 'minimal WiFi Blink - prepare for upload'.

Alternatively on upload the ACORN could be set to such a built in core 'factory bootloader Blink' that could never be wiped - not unlike the 'watchdog will jump it to a loop where it watches for a new upload'.  When I heard there were 'two copies' in flash - I assumed one was a "fixed" working core.

I see limited value in reverting to the prior code that was "working" [but needed replaced for some reason!]:
> takes up valuable program space
> could confuse a user when subtle prior bad behavior persists
> may relate to the failure to upload

Always reverting to core functioning 'blink upload' code at the start of an upload would seems to be a cleaner more consistent cleaner starting point, as long as it presented itself in the same network that last worked to facilitate the next upload.

When I set up a new router I can save off the configuration settings to reload.  Perhaps something like this could work - where a minimal dev environment is established and then after uploading two times without changes and approved it could be marked as the default backup.  That was really easy to type - not sure how hard it would be to do.  Ship default behavior of always swapping uploaded code, then allow the user to specify 'compare both uploads' and mark that upload as the copy to establish as 'fixed', and then start every upload pointing to that 'fixed' code space and always overwrite the last uploaded rather than the prior.  As planned revert to the 'watchdog will jump it to a loop where it watches for a new upload' when all else fails.