[WIP] icm20689: track consecutive failures and trigger reset

[dagar]

• potential fix for test rack CUAV v5 nano icm20689 persistent transfer errors #14644

[dagar]

This appears to have been successful in recovering the "stuck" icm20689 on a particular CUAV v5 nano with no power cycling.

[dagar]

It's not clear to me this is much of a problem in general, but in an effort to make these drivers as robust as possible I'm going to implement the consecutive failure count + reset everywhere.

[dagar]

That was effective in catching the problem and triggering a reset, but I'd prefer to avoid it entirely if we can.

Next I'm going to try reducing the SPI bus speed for the icm20689.

[dagar]

Next I'm going to try reducing the SPI bus speed for the icm20689.

No impact on the bad board. I'll look at adding the self test.

[dagar]

I'm fairly certain there's an actual problem with the icm20689 on the test rack's CUAV v5 Nano. This is actually a good case to review from the driver's perspective because we can catch the error fairly early and trigger a reset, but that might actually be the wrong thing to do. The sensor will reset, work for a brief period, then start producing errors, repeat. The end result is enough valid data the sensors module doesn't actual flag a timeout.

[dagar]

Fixed in master.