@MrD-RC Tested it with a quad, having the STATS enabled.. And it worked as you described.

I also ran some back to back tests with the current firmware and this commit. And could replicate @rts18 findings with the current firmware. And found as he did, that having a higher data logging rate caused an increased prevalence of this occurring.
And noticing that it didn't happen every time the FC was disarmed, likely indicates the scheduler was being pushed as the eeprom saving was taking place at disarming, when ESC reboot did happen. And at those times the Saved OSD message would occur at the instant of disarm and emergency rearm.

But when I tested it with this commit. It always delayed the eeprom save until after the emergency rearm window had expired.. And only then would the ESC occasionally reboot, when the Saved message was displayed... But by that time it was on the ground after being auto disarmed. Which is the desired effect.

I'm surprised it appeared to work @Jetrell because it shouldn't as far as I can see simply because the IN_FLIGHT_EMERG_REARM flag can only be set AFTER rearming within the 5s timeout period. It isn't set when you disarm so can't be used to indicate you're within the 5s timeout period ... or maybe I'm missing something ?

@breadoven Well.. It did take some getting it to show up in the first place.. This was done by disarming and rearming a good half dozen times, one after another in flight.. And it only rebooted the ESC's once.
While in the test with this commit.. I ran the same cycling maybe 18 times.. And I never seen it happen once.

the IN_FLIGHT_EMERG_REARM flag can only be set AFTER rearming

I guess it was because of the continual disarming and rearming, one after another. Meaning the flag condition was meet.. Either that, or I just got lucky and it didn't happen again.. And I worn out my arming switch for nothing. :-)

When I looked through the code. It appeared that the IN_FLIGHT_EMERG_REARM status is set on disarm, when the function is called to check if emergency rearm is allowed. Then the IN_FLIGHT_EMERG_REARM status is removed 1 second after arming. That would be ideal. But I could check the function directly.

[edit] I was wrong about the above.

I did test with HITL this morning, and noticed that it wasn’t working as expected. There were system messages issues, which I’m working on fixing. I also saw ** SETTINGS SAVED ** when I shouldn’t have. So there is still some work needed.

Now tested in HITL and working as expected.

In flight, if you re-arm within 5 seconds, the settings are not saved. After the 5 seconds expire, the settings are saved. Once landed, disarming by switch or detection saves the settings after a brief pause.

https://youtu.be/5fSwQVvQkg4

One issue with this is the IN_FLIGHT_EMERG_REARM flag always gets set on disarming in flight and will remain set when you rearm even after the 5s emergency rearming timeout period expires. Not really a big issue but it does negate the 5s rearm time window in regard to the Home Position and Home Altitude reset override. Bypassing arming checks will still be restricted to the 5s time window however so this isn't an problem at least.

Simple fix for this would be to disable the IN_FLIGHT_EMERG_REARM flag at the start of the emergInflightRearmEnabled function so it always has to be re-evaluated every time the function is called.

@breadoven sounds good to me. I can add this if you like. I was going to add system messages with a countdown for emergency rearm.

[EDIT]
Added to #9688

As a note. The above suggestion was removed from #9688 as it caused issues. However, the home position and altitude are not reset. Looking at the code, it shouldn't reset either while IN_FLIGHT_EMERG_REARM is enabled. It seems fine in HITL.

I think the branch should be restored and this change reverted.

There is something strange going on. I won't have time to get this sorted before the 14th deadline.

I have reverted the changes made by this PR (#9715). I will combine the changes still needed from this PR in to #9688 and continue working there.