Uh no. On all counts.
I'm thinking you have not understood what I wrote.
The original post asked 3 questions. 1 (software), 2 (h/w), 3(h/w)
From real world experience h/w related issues can trigger a s/w lockup issue.
The AVR h/w and bus is still working but the i2s code is stuck in a hard loop forever due to a lack of robustness in the s/w state machine.
In post #15, I tried to explain (perhaps pooly) that on the AVR when users have reported a "locked up" i2c bus or "i2c slaves no longer working", it can and is often actually is locked up i2s s/w that has locked up the AVR processor rather than h/w or an actual locked up i2c bus.
(Occasionally a slave can get into a confused state and stop responding)
Yes the s/w lockup issue is triggered by misbehaving h/w that can often be modified to reduce the potential. But even if the h/w is made more robust, the potential s/w lockup issue is still there and could still trigger and lockup up from an unanticipated h/w trigger.
i.e. for a robust system, both h/w and s/w need to be addressed.
And for sure it is best to try to avoid known s/w lockup possibilities.
I offered two suggestions for how to avoid or recover from the s/w lockup.
Maybe it wasn't clear but I was also assuming, that h/w best practices would also
be incorporated to try to reduce or even eliminate the h/w triggers of the s/w issue.
And then also add the s/w fix to avoid/recover from a potential i2s s/w lockup.
This has been a known AVR I2C s/w issue for a LONG LONG time (like 15+ years).
I2S s/w was even updated to fix these lockup issues.
Testing has verified the problem and verified that adding timeouts to the i2s code tight state change spin check loops eliminated the s/w lockup.
The I2S code was modified to put timeouts into these spin loops but because the implementers and the arduino.cc maintainers were unsure about unintended consequences of these timeouts, they are left off by default.
An easy way to try to recover from this s/w lockup if it happens is to use the watchdog timer, as I mentioned in post #15
This will reset and fully restart everything in the AVR to get things going again.
However, this is not assured to get things going again since in some cases a slave can get confused and get into a weird state. This is rare but can happen. If the slave is in weird confused state, sometimes re-initialization won't clear it and a power cycle of the device is needed.
I actually have such a device that I use for testing.
---- bill
More below for those what want more details.
------------------------
One thing that adds difficulty to being able to make a sketch more robust around i2c issues is that many Wire based sub libraries like LCDs, and sensors do not bother to check Wire library return codes and don't return them back to the sketch through their APIs, so the sketch has no idea if its calls into the i2c device library are succeeding to know if it should start taking recovery measures.
What was seen during testing was that when there were bus/noise issues on the I2C bus, you often got several I2S and hence Wire library exceptions or errors before the lockup.
However It is a statistical timing thing as to when the bus signals got the corruption and is "seen" by the AVR I2S h/w and slaves relative to where the i2c transfer was in its cycle. Depending on when/where the signal corruption happens, you either get, lost write data, data corruption, a confused slave, an i2c exception from the i2s code, or the dreaded i2s s/w lockup.
These issues were typically caused by, missing pullups, poor wiring of the i2c signals, dynamically plugging/un-plugging slaves, or power issues related to using relays with high loads. Or even other external devices like a refrigerator going on/off drawing significant loads on mains power causing power issues for the 5v supply to the Arduino.
Yes, making the h/w more stable/reliable can reduce the probability of running into this s/w issue, perhaps even reduce it to zero in the right situation, but the lockup issue is still there that could eventually come back.
In my world I like to have robust implementations particularly ones that won't ever lock up, and in order to do that, the system must be able to recover from as many errors and exceptions as possible.
The AVR I2S software can and does lockup.
The h/w is still working. It is the s/w that gets stuck in a hard spin loop.
Testing has fully verified this.
If you go read the AVR i2s code and the github history you can see the multiple places in the code where this can happen and were updates were added to allow exiting these tight spin loops after a period of time that can be configured.
If Wire/I2S timeouts are enabled that will eliminate the s/w lockups, but then the sketch must always check to see if there are i2c issues, but that isn't always possible if the i2c sub library doesn't return them back up.
The other alternative is to enable the watchdog timer.
It is by far the simpler solution to get things going again.
This will reset the AVR and start all over. This will work as long as there isn't a situation where a slave has gotten into confused state that needs a power cycle.