Thanks @MatteoL, this provided valuable info, and I believe the issue with being unable to recover is related to the pipeline being flashed to the device X_LINK_FLASH_BOOTED
, I missed the "standalone application" detail from your original post. About the bootloader in use, all good.
One more detail would be good to check, if the IMU has its firmware properly flashed, as it shares the SPI bus with the NOR flash and otherwise may interfere in the bootup process. Even if it's not used in the pipeline. I updated the above script, just check for the FW version to not be 0.0.0
, but a line like below:
IMU: BNO086, FW version 3.9.9
or
IMU: BMI270, FW version 1.0.0
Another important thing to check, was the flashed application updated again upon upgrading to depthai 2.26.0.0
? Even if the pipeline was not changed, the firmware package being flashed consists of the application firmware (a 24MB binary embedded in the depthai library) + the user pipeline. And we included a few stability bugfixes in the latest release.
And the question about the watchdog makes sense again now. When the pipeline is loaded by the host, an extra watchdog thread is created that pings periodically the device. Even with the flashed pipeline case, a watchdog thread is created on device which checks a few things internally, but I see there is a possibility that only the external communication (Ethernet in this case) may break for some unexpected reason, and then this watchdog couldn't intervene. It may make sense in such applications to have a Script node being able to maintain a watchdog or issue a reset. We'll follow up on this.