So far firmware worked with assumption that it'll get 2 BNO reset responses, which is not always true.
In my testing it seems like first reset is performed automatically on BNO power on, then second is performed on demand by firmware.
When BNO was earlier in working order and firmware is restarting (because ESP crashed or was resetted without power cut) BNO will not generate first reset, which was assumed to happen in firmware so far. So BMI driver was waiting for 5 seconds starving software watchdog set to 3 seconds by default.
This change:
makes firmware waiting only one second for first reset (to accelerate boot time when it's not happening)
feeds watchdog during that waiting, just in case, so if will not crash even if we change timeout to 5 seconds again
for ESP32 there is no clear API to fetch watchdog, but it doesn't seem to be affecting this code (it doesn't trigger even on very long timeout).
So far firmware worked with assumption that it'll get 2 BNO reset responses, which is not always true. In my testing it seems like first reset is performed automatically on BNO power on, then second is performed on demand by firmware.
When BNO was earlier in working order and firmware is restarting (because ESP crashed or was resetted without power cut) BNO will not generate first reset, which was assumed to happen in firmware so far. So BMI driver was waiting for 5 seconds starving software watchdog set to 3 seconds by default.
This change:
Should help with https://github.com/SlimeVR/SlimeVR-Tracker-ESP/issues/264