CATEGORY: MITRE CWE-227: Improper Fulfillment of API Contract. REFERENCE: http://cwe.mitre.org/data/definitions/227.html. EXPLANATION: While the ticks obtained from the hardware register in getTimeMillis will wrap at 0xFFFFFFFF, the computed millisecond value will wrap at a much lower boundary: due to the two divisions, the local variable millis will wrap at 0xFFFFFFFF divided by HAL_CLOCK_FREQUENCY_MHZ divided by 1000. CONSEQUENCES: Upon a wrap-around (laterTime is smaller than earlierTime), timeDiffMillis will return a difference that is far too big, leading to undeserved notifications of the ErrorManager. BUGFIX: While various bugfixes are conceivable, the most efficient solution is to record the time in the 'native' time unit (ticks) and convert the time to milliseconds as late as possible -- when comparing against constants given in milliseconds. Thus, getTimeMillis becomes getTime: uint32_t TemperatureMonitor::getTime() const { return HalGetClockTicks(); } and timeDiffMillis needs to be adapted like this: uint32_t TemperatureMonitor::timeDiffMillis(uint32_t earlierTime, uint32_t laterTime) const { uint32_t diff; // Normal case, no wrap-around. if (earlierTime <= laterTime) { diff = laterTime - earlierTime; // 'laterTime' has wrapped-around 32-bit boundary. } else { diff = (0xFFFFFFFF - earlierTime) + laterTime; } return diff / HAL_CLOCK_FREQUENCY_MHZ / 1000; } REMARKS: It is not easy to decide on a bug category or where exactly the bug is located in the code. Taken individually, the original versions of getTimeMillis and timeDiffMillis are both correct. The problem arises because the postcondition of getTimeMillis doesn't fulfill the (implied) precondition of timeDiffMillis: getTimeMillis doesn't return a value that utilizes the full value range of a uint32_t. This bug is a good example of cases where the use of correct parts still results in an incorrect system when the contract of the parts is not respected.