The TMP112 is a low-power digital temperature sensor from Texas Instruments with an I2C/SMBus interface, a 1.4 V to 3.6 V supply range, an operating temperature range of −40 to +125 °C, and uncalibrated accuracy that is variant- and window-dependent — for example, ±0.5 °C max for the A grade (0 to +65 °C at 3.3 V) and ±1.0 °C max over the full −40 to +125 °C range for every variant. Resolution is 12-bit with an LSB of 0.0625 °C, and current is 7.5 µA max active / 0.35 µA max shutdown. It's aimed at battery-powered and portable products, HVAC and building-automation sensors, cold-chain logging, and embedded thermal management — anywhere a small digital temperature sensor that sips microamps fits.
Now the myth — and it's a natural one to believe. "The TMP112 is just a TMP75-compatible part; wire it to the bus, read address 0x48, done." The register format is indeed TMP75-compatible, but the part has several behaviors that a TMP75-style mental model gets wrong: the address depends on which package variant you have, the part wakes up in continuous conversion at 4 Hz with alert limits preset to +80 °C/+75 °C, and the shutdown current spec only holds if you leave the I2C bus idle. Let's go through what it actually is, how to integrate it, what to watch out for, how to test it, and how to fix it when it misbehaves.
Wiring the TMP112 (How do I integrate the TMP112 into a design?)
The TMP112 is a two-wire slave device. The essentials:
- Supply: 1.4 V to 3.6 V. Temperature error versus supply is essentially flat above roughly 1.5 V, so running at a comfortable mid-range supply removes supply variation as a meaningful error contributor.
- Bypass capacitor: required, 0.01 µF, placed as close as possible to the supply and ground pins. This is not optional — the datasheet calls it required for proper operation. On noisy or high-impedance supplies, add extra decoupling beyond that minimum.
- Optional RC filter on V+: for extra supply-noise rejection, use a series resistor R(F) < 5 kΩ and a bypass cap C(F) > 10 nF.
- Pull-ups on SCL, SDA, and ALERT: all three are open-drain and need pull-ups; the recommended value is 5 kΩ. You can go lower or higher, but you must not push more than 3 mA through any of those pins. Use the minimal pull-up current you can get away with, especially on SDA and ALERT — excess sink current self-heats the part and degrades the very measurement you're making.
- Pull-up voltage: SCL/SDA may be pulled up to a supply equal to or higher than V+, so level-shifting up is legitimately supported. But mind the absolute maximum ratings: SCL, SDA, and ADD0 tolerate −0.5 V to a fixed 4 V regardless of V+, while ALERT's absolute-maximum voltage is (V+ + 0.3) V, capped at 4 V. If you level-shift SCL/SDA to a higher rail, do not pull ALERT up to that same rail — with V+ at 3.3 V, ALERT tops out at 3.6 V, and exceeding it can permanently damage the part. The supply itself (V+) also has a 4 V absolute-max ceiling.
- Address strap (ADD0): tying ADD0 to GND, V+, SDA, or SCL selects one of four addresses, so up to four devices can share one bus.
That last bullet hides the biggest wiring trap, so it deserves its own paragraph. On the SOT563-6 TMP112 (the address+alert variant), ADD0→GND gives address 48h, V+ gives 49h, SDA gives 4Ah, and SCL gives 4Bh. But the TMP112D in the 5-pin X2SON package maps the same four straps to 40h–43h instead. If you swap packages between board spins and keep the same firmware, the part won't respond at the address you expect — not because the board is broken, but because the device is alive and ACKing at its variant's address instead. Know which variant you have before you write the driver.
For placement, the datasheet doesn't prescribe anything, but the practice is clear: put the sensor in good thermal contact with the object you actually want to measure, and keep heat sources — the MCU, power converters, high-current traces — away from it. Otherwise you'll be measuring your PCB, not your product.
What the TMP112 actually does on power-up (What behavior should I expect before I configure anything?)
Here's where the TMP75-compatibility assumption starts to cost you. The power-up state is:
- Continuous conversion mode at 4 Hz (the default CR1/CR0 setting), with a typical conversion time of 10 ms. Programmable rates are 0.25, 1, 4, or 8 Hz.
- T_HIGH = +80 °C and T_LOW = +75 °C by default. If your product's ambient is anywhere near 75–80 °C, or you simply never programmed the limits, the ALERT pin can assert out of the box.
- Comparator mode (TM=0), active-low alert polarity (POL=0), 12-bit normal mode (EM=0).
- Configuration register reset value: byte1 = 0b0110_0000, byte2 = 0b1010_0000.
The fix for battery applications is shutdown and one-shot operation. Write SD = 1 to force shutdown — the part finishes its current conversion first, then drops to typically < 0.15 µA with only the interface alive. From shutdown, write a 1 to the OS bit to trigger exactly one conversion; the device auto-returns to shutdown afterward. During the conversion the OS bit reads 0 and flips to 1 when done — a free, deterministic "conversion complete" flag you can poll instead of hard-coding a delay.
The power-budget myth (Why is my TMP112 drawing more current than the datasheet says?)
The second myth: "7.5 µA max active, 0.35 µA max shutdown — I'll just use those numbers for battery life math." Both numbers are real, but both are conditional on bus activity, and the conditions matter more than people expect:
- Active, bus idle, default 4 Hz: 4.8 µA typ / 7.5 µA max. At the 1 Hz rate bank: 3.2 µA typ / 5 µA max.
- Active with the bus actively clocked: 10 µA typ at 400 kHz, rising to 40 µA typ at 2.85 MHz.
- Shutdown, bus idle: 0.15 µA typ / 0.35 µA max — but shutdown with the bus clocked at 400 kHz draws 5.5 µA typ, more than fifteen times the headline figure.
- Measured average current scales with conversion rate: roughly 3.0 µA at 1 conversion/s up to ~6–9 µA at 8 conversions/s near room temperature.
The takeaway: a host that keeps polling the bus defeats shutdown entirely. If battery life matters, put the part in shutdown, take one-shot readings, and leave the bus idle between them. And when you verify power on the bench (more on that below), measure at your operating point — conversion rate, bus speed, and bus duty cycle all move the number.
A related timing fact: a conversion takes ~10.2 ms, essentially flat across temperature and the full supply range. Budget that delay after triggering a one-shot before reading the result — or just poll the OS bit.
Accuracy: read the fine print on the variant (How accurate is the TMP112, really?)
Myth number three: "±0.5 °C is the accuracy." It's the accuracy of one grade, inside one window, at one supply. The A grade is ±0.5 °C max from 0 to +65 °C at 3.3 V, and ±1.0 °C max over the full −40 to +125 °C range. The B grade offers the ±0.5 °C window at 1.8 V. The accuracy is uncalibrated and variant/window dependent — so pick the variant whose rated window and supply match your actual operating point, not the one whose headline number looks best.
One more format detail that trips people up: the temperature register is 12-bit by default (one LSB = 0.0625 °C, two's complement for negatives), and setting the EM bit moves the temperature register and T_HIGH/T_LOW to a 13-bit format — the point being to measure above +128 °C, since 12-bit mode tops out at +127.9375 °C. Because EM changes the limit-register format too, write EM first, then program T_HIGH/T_LOW in the matching format — a limit written in 12-bit form while EM=1 will be interpreted as 13-bit and land at the wrong threshold. Also note there is no EEPROM emulation or write-protect anywhere: T_HIGH and T_LOW are volatile RAM that revert to +80 °C/+75 °C on every power-up, so your firmware must reprogram them each boot.
Bring-up and verification (How do I test a TMP112 on my board?)
A sequence that catches essentially every integration mistake:
- Bus scan. With ADD0 strapped per your design, the TMP112 should ACK exactly one address — in the 48h–4Bh group for the SOT563 variant, or 40h–43h for the TMP112D X2SON — and nothing else on the bus should collide.
- One-shot functional test. Write SD=1 (shutdown), then write OS=1. Wait at least 10 ms (or poll OS until it reads 1), then read the two temperature bytes, MSB first: byte 1 carries T11–T4, byte 2 carries T3–T0 in 12-bit mode. A read transaction itself is fast (< 20 µs).
- Sanity-check the value. It should sit in the −40 to +125 °C operating range at your ambient. A reading far outside that with no thermal stimulus means a decode or addressing fault, not a hot board. Then warm or cool the part and confirm the reading tracks monotonically — a static reading usually means a bad solder joint on SDA/SCL, not a dead sensor.
- Alert-path check. Set T_HIGH just above ambient, enable interrupt mode (TM=1), and force the trip. Then exercise the SMBus alert response protocol: the host sends the ALERT command (0001 1001), the part replies with its address on SDA, and the LSB of that address byte tells you high- versus low-side — bit high means over T_HIGH, bit low means under T_LOW. With multiple alerting devices on the bus, arbitration resolves the response and the lowest two-wire address wins; the winner clears its alert status and the losers keep theirs. On X2SON-5 address-only parts (TMP112D) where the ALERT pin isn't brought out, alert status is still readable this way in software.
- Power-draw verification. Measure actual current at your conversion rate and bus speed. Remember: a clocked 400 kHz bus in shutdown still draws ~5.5 µA typ, so idle the bus before you trust a shutdown-current measurement.
On the bus itself, the TMP112 supports fast mode (0.4 MHz), fast-mode plus (1 MHz), and high-speed mode up to 2.85 MHz, with a minimum clock of 1 kHz in all modes.
Troubleshooting (Why is my TMP112 circuit misbehaving?)
When a board doesn't work, these are the failures that show up again and again:
- No ACK / no communication. First, check the address against your package variant, not just your strap: SOT563-6 maps ADD0→GND/V+/SDA/SCL to 48h/49h/4Ah/4Bh, while the X2SON-5 TMP112D maps the same straps to 40h–43h. If the part doesn't ACK at one group, scan for the other before assuming the board is dead. Second, check your clock speed — the interface has a timeout: if SCL is held low for ≥ 30 ms (typ) between start and stop, the interface resets and releases SDA, waiting for a fresh start. A bit-banged bus clocked too slowly, or a stalled transaction, makes the part silently drop everything. Stay above the 1 kHz minimum clock. Third, confirm pull-ups exist on SCL, SDA, and ALERT — without them the open-drain lines never reach a valid high level.
- Reading a stale or wrong register. The 8-bit pointer register selects the active register (00 = temperature, read-only; 01 = config; 10 = T_LOW; 11 = T_HIGH), and it resets to 00 on power-up — so a fresh read returns temperature by default. But after any other register access the pointer has moved, so issue the pointer byte explicitly before every temperature read. Don't rely on "it worked last time."
- ALERT firing unexpectedly. Check the defaults: T_HIGH = +80 °C, T_LOW = +75 °C, continuous conversion at 4 Hz. If you never wrote the limits and your environment is warm, the alert is doing exactly what it was factory-programmed to do. Also note that a general-call Reset command reverts the alert mode to comparator (TM=0) — if you'd configured interrupt mode, an accidental reset silently changes the alert's behavior. In interrupt mode the alert is latching: it asserts on the T_HIGH excursion and stays active until you read any register, the device answers the SMBus alert response address, or you put it into shutdown — and it re-arms only after temperature falls back below T_LOW. If spurious alerts from thermal transients are the problem, configure the fault queue (F1/F0) so N consecutive fault measurements are required before asserting.
- Everything looks random. Read back the configuration register and compare against the documented power-up value (byte1 = 0b0110_0000, byte2 = 0b1010_0000). If it doesn't match, the device hasn't reset cleanly or has been left in a stale mode by earlier traffic.
- Readings track the PCB instead of the product. That's thermal layout, not the sensor — revisit placement and heat-source separation as described above.
Known limitation: the datasheet's θJA (junction-to-ambient thermal impedance) table could not be fully verified for this article, so no specific thermal-resistance value is quoted here. Given the part dissipates only microamp-level power, self-heating is negligible in practice, but don't treat any θJA number you find elsewhere as confirmed against this datasheet.
The bottom line
The TMP112 is genuinely TMP75-compatible at the register level, and that compatibility is real and useful. But treat it as a blank-slate clone and you'll hit the four traps: variant-dependent I2C addresses, power-up defaults (4 Hz continuous conversion, 80/75 °C alert limits) that don't match a battery product, bus-activity-dependent current that invalidates naive battery math, and volatile alert limits you must reprogram every boot. Wire it with the 0.01 µF bypass and 5 kΩ pull-ups (keeping ALERT's pull-up at or below V+ + 0.3 V), put it in shutdown with one-shot reads, program the limits on every power-up, and verify with a bus scan plus a one-shot test — and it will do exactly what the headline specs promise.
Part page: TMP112.