External Reset on Series 1

[coderatchance]

Hello all,

after some reading I finally know how the reset should works on these new tinys.
So, I am interested to use the external reset, namely I would like to reset the tiny with a simple "reset button".
In this case I am guessing the code would start from the begining with all the setup, etc.
Can this be done with the External Reset | RSTCTRL_EXTRF_bm | 1 << 2 | 0x04 | When reset pin is brought LOW ?
However, I am not familiar with this type of coding, so does any of you know the manual to understand this type of coding ?

Best.

[SpenceKonde]

There are a ot of challenges for this on series

1. If you use the real reset pin, you can fuse PA0 to act as reset and all's well, except you need an HV programmer to change waht you've written.
2. If you use ErsatzReset there are a number of ways that it is not bulletproof.
3. If you are ever "pressing" you own reset button (via a jumper to an output pin), on any AVR,, you are doing it wrong the reset cannot be trusted,, don't do that, it's specifically contraindicated in the documentation!

[SpenceKonde]

See the two ErsatzReset examples included with the core under the megaTinyCore "library" (the examples there are a mix of actual library examples, but more of them are things that aren't specific to a library, but to the core in general and don't make use of megaTinyCore.h (that's a file with a few helper functions). Like for example demonstrating how to set up ErsatzReset

(Ersatz is the german word for substitute, which spread around the world to non german speaking countries after WWII because the germans gave POWs "ErsatzKaffe" or however they spelled it instead of coffee. So it reached the world as the POWs returned, now with strong connotations of an inferior substitute. And that is the meaning of it here)

There is no way to ever have the EXTRF flag set on a 1-series unless it is set to use PA0 as reset, though there are as noted other ways to reset the chip. However, when user code runs, If there is EVER ANY NONZERO VALUE in RSTCTRL.RSTFR, you are in a can't happen situation: The bits are ONLY set upon reset (and that's the only register not reset in all resets), and at the very earliest possible moment, the core ensures that the following happens:

1. RSTFR is read.
2. A software reset is issued if RSTFR was found to be zero - this means that execution got back to 0x0000, WITHOUT ANYTHING BEING RESET (due to smashing the stack, CALLing a null pointer, enabling an interrupt without defining the ISR - stuff like that), and the device will behave incorrectly in unpredictable and near arbitrary ways (especially if using optiboot, since the app in these cases frequently winds up bouncing around the sketch like a pingpong ball in a clothes dryer before it hits reset, if you are using optiboot, and you had a 25kb sketch loaded, then upload a 10kb one, there are still 15kb of zombie code sitting there in the flash. It's unreachable so it doesn't matter unless a software bug smashes the stack and which point it is totally reachable, and it is extremely hard to predictwhat it will do other than be wrong, and after the dirty reset it will just at least as broken as it was before it, and likely more so (for example, To upload to an optiboot board after a dirty reset wouldn't work at 115200 baud - but 691200 baud would work! (WTF? Well, optiboot runs at the default startup clock speed, with the /6 prescaler enabled - that doesn't get changed until the sketch starts - but in a dirty reset that has already happened, but the bootloader (like everything else that runs before setup() is called) assumes that it started with all the registers in power on reset state.
3. If using optiboot, and that value is an optiboot entry condition, it runs the bootloader (all the entry conditions are busted in most recent release. they all run on I think all resets and the only different between the 9 entry conditions is the 8sec vs 1 sec (ie I built 9 binaries per part class, but 7/9ths of them were duplicates!), because I didn't know that I had to edit parseoptions.mk in addition to everything else in order for make to not ignore parameters I was passing it. I thought I could in the makefile specify that. Nosireee. You don't just have to say to pass this option in the makefile you need to also go into parseoptions and tell it that no you weren't just passing that parameter for fun, you were passing it becausse you wanted it to have an effect. I could not create even the simplest program in C if I didn't have something to manage the build process. That whole thing is a dark art to me. Given no IDE to help me, If I could hand write text files, I could, very slowly and painfully and with piles of paper on my desk beting covered in scrawled notes, write a simple program directly in machine code.
   I could not write even the simplest C program. Well, I mean, I could write the program. I couldn't compile it because I don't know how to use make and cannot create makefiles de novo. Apparently I can't even edit makefiles successfully!!), and in this case, it DOES NOT reset the RSTFR just yet. However, after doing any bootloadery things, it will then exit by triggering a WDT reset. Since the entry condition is always that WDRF not be set, and one out of a number of other bits set. optiboot will not run twice in a row (if the chip is empty, it will appear to, but it's alternately reaching the end of flash, wrapping around, setting off the dirty reset trap and software resetting, whereupon it runs the bootloader again, and if nothing is uploaded this repeats indefinitely because wtf else is an empty chip but for the bootloader supposed to do?
4. Otherwise, that value is stored to GPIOR0, RSTFR is CLEARED, and the application is started.

On non-optiboot boards the same logic is performed, but without the entry condition stuff. We check the flags, software reset if they're 0, otherwise clear them, and store the value to GPIOR0 so that the application can easily retrive them

So the low 6 bits of GPIOR on startup contain the reset flags at startup. GPIOR0 is never used by the core or any included libraries after setup() is called. so if you need to use that GPIOR you can just write 0 to it in setup, after reading the reset flags from it if you care).

See https://github.com/SpenceKonde/megaTinyCore/blob/master/megaavr/extras/Ref_Reset.md for information (more than you wanted to know) about why no modern AVR program that does not always clear the reset flags on startup and force a reset if there aren't any is acceptable under any circumstances. Cores which do not do this (like the official cores, and even MegaCoreX) will not appear to reset unexpectedly any more or less than the same code from one of my cores. But the number of ways you could hang or bootloop a chip (assuming your sketch does not itself trigger immediate bootloops - I'm talking about sketches that run for a while, then you see the tripleblink of optiboot and then the board is either non-responsive or bootloops until reset) is decreased dramatically. Only if you smash the stack and overwrite the return address *with a value that happens to be the word-addressed location in the flash of a while () loop that, if you entered it in the state you were in when you smashed the stack, is always and will remain true forever. C requires that each sketch have at least one of these, so that it has something to do if main() were to return, since there's no OS to exit to. but this also counts things like if you landed in a while (!(REGNAME & 0x04)) while the peripheral that was associated with wasn't running, orhadn't been asked to do anything that would set bit 3 (as in, you landed between the point where you set up the thing that the loop waits on). Smashed stacks result in you landing at deterministic yet unpredictable points anywhere in the flash, bounce around like a pingpong ball in a clothes dryer (never put a pingpong ball in a clothes dryer, at least not a regulation one, those are 50% nitrocellulose (major active component of smokeless gunpowder, and ridiculously flammable) - but that makes it a better analogy - it'll bounce around executing code with wrong values in variables and returning to things that arten't meabt to be addresses in flash.... and probably set your laundry on fire sooner or later)

The two high bits of GPIOR0 are not changed on startup unless using tuned internal oscillator where they are used for error reporting (what the hell am I supposed to do to give uses a way to find out that the reason the tuning they want isn't being used is that we tried that speed when we ran tuning, but determined that the chip crashed if you tried to run it that fast)? We have no guaranteed way to send an error message, and no other decent way to get data from init to user code! just set it zero in setup (cost - 2 bytes 1 clock)