I’m planning a monitoring project where reliability is important. I want to use ATTINY13A or 45 for it’s reliability. I know Arduinos are prone the the “just try a reboot” issues. I don’t think I’ve ever seen an ATTINY do that, aside from bad code. How about you guys? Has anyone seen an ATTINY that “just needs a reboot” and know it wasn’t from bad code?
any MCU can get stuck even if you think the code is perfect
you can only give it a very long time test to see if its stable
Anduril switch bounce —> get stuck in reboot loop
even just replacing an old momentary switch with a new might trigger such a problem on a system that ran years without any problems before
I would completely agree with Lexel. I have several Wemos D1’s and RPi’s. All of the D1’s are set up alike with the same software and hardware, one of them locks up more often than the others and most of them never lockup between code upgrades. I have seen the same behavior with the RPi’s over time as well. I assume that the ATtiny could lock up, have never had one do it though.
I totally agree it’s possible, and you should not blindly trust anything electronic.
But for minimizing curse words, ATTINY seems to be the way to go.
I dare to say that the hardware of these simple AVR chips is almost bug free or that almost all bugs were found and documented. The instruction set is so small and simple that it is easy to test, same for the components of the microcontroller.
All issues you might have heard of are a result of programming, compiler or integration errors. There’s also not much difference between an Arduino (ATmega) and an ATtiny.
Btw: For many situations you can use the watchdog to reset the microcontroller if it locks up.
wasn’t there also something like worn out memory on these if values stored too often?
Yes, as documented in the datasheet. For an ATtiny13: 10,000 erase cycles for the flash and 100,000 for the EEPROM. But that’s the lower limit.
I wouldn’t really say attiny is particularly any more or less stable than other chips. It even has a facility built in to reboot itself when an error is detected.
When the WDT is enabled, if it doesn’t get a confirmed response by the second time it fires off, it’ll reboot the MCU. It assumes something went wrong and the best thing it can do is reboot. This can be used to prevent the MCU from ever getting completely stuck.
However, if the boot code doesn’t clear this condition, it’ll generally get stuck in a reboot loop.
The reboot loop can be an easy way for a user to detect that an error happened, since the error might otherwise go unnoticed. But clearing the WDT status on boot is a good option too, if you want it to boot up normally and keep working. Of course, that doesn’t guarantee that whatever caused the error in the first place isn’t still happening…
For example, a really weak ground connection (and other forms of electrical noise) has been known to cause reboots in attiny-based flashlights… regardless of what code is running on it. The power coming into the MCU is so dirty that the MCU can’t function correctly, and it reboots itself. The attiny13a is less prone to this than other chips though, since it can operate well outside its specs. The other attiny chips I’ve tried are less tolerant.
The replies here are not answering your question, they are mostly referring to bad code. I’d say no, besides bad code the ATtiny does not need rebooting.