CHANGELOG.md

@@ -16,6 +16,11 @@ will consitute of a breaking change warranting a new major release:
 
 # [unreleased]
 
+## Fixed
+
+- TMP1075: Set dataset invalid on shutdown explicitely
+- Small fixes for TMP1075 FDIR: Use strange and missed reply counters.
+
 # [v6.0.0] 2023-07-02
 
 - `q7s-package` version v3.2.0

mission/system/tcs/TmpDevFdir.cpp

@@ -20,7 +20,7 @@ ReturnValue_t TmpDevFdir::eventReceived(EventMessage* event) {
       // We'll try a recovery as long as defined in MAX_REBOOT.
       // Might cause some AssemblyBase cycles, so keep number low.
       // Ignored for TMP device, no way to power cycle it without going to OFF/BOOT mode.
-      // handleRecovery(event->getEvent());
+      setFaulty(event->getEvent());
       break;
     case DeviceHandlerIF::DEVICE_INTERPRETING_REPLY_FAILED:
     case DeviceHandlerIF::DEVICE_READING_REPLY_FAILED:
@@ -29,7 +29,9 @@ ReturnValue_t TmpDevFdir::eventReceived(EventMessage* event) {
     case DeviceHandlerIF::DEVICE_BUILDING_COMMAND_FAILED:
       // These faults all mean that there were stupid replies from a device.
       // With now way to do a recovery, set the device to faulty immediately.
+      if (strangeReplyCount.incrementAndCheck()) {
         setFaulty(event->getEvent());
+      }
       break;
     case DeviceHandlerIF::DEVICE_SENDING_COMMAND_FAILED:
     case DeviceHandlerIF::DEVICE_REQUESTING_REPLY_FAILED:
@@ -40,7 +42,9 @@ ReturnValue_t TmpDevFdir::eventReceived(EventMessage* event) {
         break;
       }
       // else
+      if (missedReplyCount.incrementAndCheck()) {
         setFaulty(event->getEvent());
+      }
       break;
     case StorageManagerIF::GET_DATA_FAILED:
     case StorageManagerIF::STORE_DATA_FAILED: