yes, from the video it does look like the flight controller rebooted. This doesn’t necessarily mean it was a software issue though of course. The most common cause is an issue with how the flight controller is being powered. Can you find the log after this one? It’s probably numbered 139 and if we can find that then it will have a line somewhere that tells us if it rebooted because of a software failure or not.
Thanks for the log, so we can confirm that this is a reboot in flight due to a software reboot because these messages appear in the logs
MSG, Restored watchdog attitude 1 16 196}
So this is very bad of course. We suspect this is caused by the I2C storm issue that is fixed in Copter-3.6.11 but it’s hard to be completely sure. As @tridge says above, if you’ve got a tlog that may tell us.
I’d highly recommend upgrading to Copter-3.6.11 if possible. It should be a smooth upgrade.
I’ve been reading some other posts that mentioned a watchdog rebooting the flight controller while in flight. It makes sense for airplanes, they glide. Copters on the other hand go straight down… is there any reason to have it for copters? Is it new code for 3.6? Finally is there a link that talks about the I2c storm issue you mentioned?
Will provide the tlog as soon I get it.
@samucs, yes, this is new for 3.6.10 but to be clear, the flight controller was locking up one way or another. The change in behaviour is just that it restarted and now we know it was caused by some kind of software failure. Hopefully we can get to the bottom of this. Txs for the report.
Yes, I think what Randy is saying is without the watchdog the FC would have locked up anyway but it wouldnt have rebooted. The idea is with the watchdog and reboot there’s at least an outside chance of recovery, or at minimum some evidence.
The first crash that we have subsequently attributed with some confidence to this issue was on April 15th, but it wasn’t until August 25th that the underlying cause was found. The issue is fixed in copter 3.6.11 and plane 3.9.11.
It is likely there were crashes before April due to this issue but we had no way to attribute them. It wasn’t until we had watchdog support that we could distinguish between a software bug and a hardware fault for this type of failure.
For the 4.0 releases we’ve added in a more generic method of preventing i2c interrupt storms of all types by limiting the number of interrupts allowed per transferred byte.