On what seems like almost a daily basis, a news flash talks about some electronic product overheating, causing potentially catastrophic problems. While an overly hot product can, of course, cause problems, the correct thermal management of the inevitable heat should be a part of sensible and prudent product design.
This article will explain the internal user-programmable registers contained in digital-output (I2C protocol) temperature sensors. Furthermore, it will delve into how common design challenges in this arena can be eliminated by using a digital temperature sensor with integrated nonvolatile memory registers (Fig. 1).
Let’s start with some background details on how an industry-standard I2C temperature sensor’s internal registers are programmed. These I2C temperature sensors, sometimes called “LM75-type” protocol-compatible devices, contain four basic internal registers:
• Pointer register
• Configuration register
• High-temperature (THIGH) limit register
• Low-temperature (TLOW) limit register
These registers enable the user to set and customize the temperature sensor’s operational settings—with the exception of the temperature register (more on this later)—during the initialization process by the host controller after power-up. The pointer register allows access to one of the four registers by “indirectly pointing” to the selected register. The configuration of TLOW and THIGH limit and temperature registers can’t be directly accessed by I2C software commands; it can only be accessed through the pointer register (Fig. 2).
The configuration register is used to control key operational modes and settings of the device, such as the temperature-conversion resolution, the fault-tolerance queue, the ALERT pin polarity, the alarm thermostat mode, and the shutdown mode. Some devices on the market also have a one-shot mode. One-shot mode is a power-saving mode to allow the device to come out of standby mode to take a temperature measurement, update the temperature register, and then return to standby mode.
The temperature register, a read-only register that stores the digitized value of the most recent temperature measurement, can simply be read to know the latest temperature measurement. The temperature register can be read at any time and, since temperature measurements are performed in the background, reading the temperature register doesn’t affect any other operation that may be in progress.
The TLOW and THIGH limit registers store the user-programmable lower and upper temperature limits for the temperature alarm. Figure 3 illustrates a typical temperature profile. For example, if the user sets the TLOW and THIGH limit registers to 85°C and 50°C, respectively, the temperature sensor will set flags and can drive its output pin to notify the host controller when either limit value is exceeded.
Challenges of Volatile Memory Registers
Now that we have covered some of the basic operations, let’s discuss common issues with setting these registers. The first issue is that these user-programmable registers are of the volatile-memory variety, which means once power is removed, the register’s stored data values aren’t saved or retained.
Since these volatile memory registers have to be updated upon each system power-up and initialization sequence, this could create a high-risk, unreliable timing event. As a result, these registers may be inadvertently misconfigured and set to the wrong settings, which could cause run-away heat issues in the product.
Have you ever thought about how many times your product is power-cycled throughout its lifetime? For some products, it may be hundreds of times, while it may be thousands of times for others, creating a higher probability for something to go wrong during the power-up sequence. This, no doubt, is a critical issue.
In the Figure 3 example, the TLOW and THIGH limit registers are set to 50°C and 85°C, respectively. However, what if the THIGH limit register was inadvertently set to 185°C due to system noise during the power-up sequence that caused just one digital bit to be set to a logic 1 state? This undesirable event may not cause the system to overheat to the point of catching fire, but it certainly would precipitate less-than-optimal, and possibly catastrophic, system performance.
For many products these days, a lot of stuff goes on during a power-up sequence, including timing of major blocks and devices within the product. The timing of these events is very critical to enable proper end-user operation.
This leads to the next question: How many times have customers returned one of your products for failure analysis, and the failure mode can’t be reproduced? The product is fully operational to your factory retesting and the report goes back to customer as, “No problem found.” One of the many objectives of prudent product design is to consider the “what ifs” in potential failure modes possibly seen by end customers, and try to eliminate them by design or feature implementation in the product validation before releasing to customers. This scenario identifies a new “what if” case to consider in your next product design when using discrete temperature sensors, regardless of protocol type or technology.
Nonvolatile Memory Registers: A Thermal Game-Changer
A potential solution for these issues is to have a temperature sensor that not only contains the volatile registers, but also contains integrated nonvolatile memory registers as well (Fig. 4).
As you can see, the configuration register and high- and low-temperature limit registers have integrated nonvolatile register versions of each. The nonvolatile registers would improve the temperature sensor’s functionality by enabling simple “plug-and-play” operation with pre-defined power-up defaults. The nonvolatile registers would retain the configuration and temperature limit settings even after the device is power-cycled, thereby eliminating the need for the temperature sensor to be reconfigured after each power-up operation.
This solution works by programming the temperature sensor’s integrated nonvolatile TLOW and nonvolatile THIGH limit registers, for example, to 50°C and 85°C, respectively. These temperature limits are stored in nonvolatile memory, securing the temperature limit values. Therefore, during the subsequent power-up sequences, the temperature sensor simply internally copies the 50°C and 85°C values from the previously preprogrammed nonvolatile THIGH and nonvolatile TLOW limit registers into the respective volatile THIGH and TLOW limit registers.
You may be asking how this solves the volatile register settings’ corruption issue during power-up. The answer is that the host controller would no longer need to send the software protocol over the I2C communication bus to set the volatile registers during each power-up sequence. It completely eliminates the register corruption risks, since there was no host controller to temperature software protocol occurrence.
This simplifies the system power-up sequence while reducing or eliminating dependency on the host controller for configuration, making the system more reliable. The additional flexibility would permit the temperature sensor to run self-contained, rather than rely on a host controller for device configuration.
Another way to make this proposed solution even more reliable is by integrating register locking features within the nonvolatile registers with either reversible or permanent settings to prevent erroneous misconfiguration. This register lockdown feature, like the one found in Microchip's AT30TS750A, would enable permanent temperature-sensor configuration and eliminate the risk by tamper-proofing the settings, thereby reducing product liability exposure.
These days, any means to increase product reliability while reducing liability exposure is a win-win business practice. Furthermore, being able to either reversibly or permanently lock down the integrated nonvolatile registers to prevent any register data changes against any future erroneous misconfiguration or data tampering would significantly increase the nonvolatile register value in a product. On top of that, it would boost system reliability and safety.
Hopefully you now have a better understanding of several design considerations for thermal management. While concerns around volatile memory registers have plagued engineers for years, new digital temperature sensors, such as the AT30TS750A, integrate nonvolatile memory registers that allow designers to bypass these time-honored torments, making this the next great advance in thermal management.