Part: MP2733GQC
Datasheet: MP2733 Rev. 1.1, 5/18/2023
Host: ESP32, I2C at address 0x4B
Application: battery-powered GPS/GSM asset tracker, single-cell LiPo permanently connected, USB 5 V input
Affected units: several, not all from the same production batch, after several weeks of continuous operation without ever losing supply
1. Summary
On affected parts, the six ADC result registers (REG_0Eh to REG_13h) stop being updated. They hold the bytes of one conversion and never change again, for weeks.
The I2C interface and the register file remain fully functional: every register reads, every write lands and reads back correctly, self-clearing bits self-clear, and both REG_RST and a watchdog expiry correctly restore POR defaults. The part reports no fault of any kind.
On the same part, a second function is also inert: BATTFET_DIS (REG_0Ah, bit[5]) can be set and reads back as 1, but the BATTFET does not open. An identical sequence on a healthy unit powers the system down immediately.
The only recovery we have found is physically disconnecting the battery with the input also removed, i.e. a true POR of the part. No I2C-reachable sequence restores it.
2. Host configuration
Schematic around the part
Application circuit around the MP2733: input path, battery, system rail and NTC network.
The host writes the following after a REG_RST at boot, and rewrites the same values once per minute:
| Register | Value | Meaning |
|---|---|---|
| REG_00h | 0x12 | EN_HIZ = 0, EN_LIM = 0, IIN_LIM = 1000 mA |
| REG_01h | 0x06 | VIN_MIN = 4.30 V |
| REG_02h | 0xCD | EN_CHG_NTC = 0, AICO_EN = 1 |
| REG_05h | 0x84 | charge current 480 mA |
| REG_06h | 0x00 | pre-charge and termination currents |
| REG_07h | 0xA4 | battery regulation voltage 4.22 V |
| REG_04h | 0x1B | EN_CHG = 1, EN_OTG = 0 |
| REG_0Ah | 0x58 | BATTFET enabled |
ADC duty cycle — possibly relevant
The host polls the ADC in one-shot mode every 200 ms, continuously, for the entire life of the product. Each poll is:
write REG_08h = 0xDD (EN_ADC_DSG = 1, WATCHDOG = 01, WATCHDOG_TIMER_RESET = 1)
write REG_03h = 0x90 (ADC_START = 1, ADC_RATE = 0)
wait 5 ms
read REG_0Eh .. REG_13h
write REG_08h = 0x95 (EN_ADC_DSG = 0)
So EN_ADC_DSG is toggled 1 → 0 five times per second, indefinitely: roughly 430,000 conversions per day, over 12 million per month. The units that failed had been powered without interruption for several weeks.
We mention this because it is the only unusual stress we can identify, and we would like to know whether this pattern is outside the intended use of the ADC.
Note also that the REG_08h = 0xDD in the sequence re-arms WATCHDOG to 01 (40 s) five times per second, so the watchdog is permanently armed and permanently serviced. This is a side effect of the host’s ADC sequence, not a deliberate choice.
3. Measurements
All measurements below were taken with the host’s periodic charger task frozen, so nothing but the commands shown was writing to the part. Both units ran identical firmware and both were connected to USB and charging, unless stated otherwise.
3.1 Full register map, faulty unit vs healthy unit
REG_00h to REG_17h, read back to back on both units:
Faulty : 12 06 CD 10 1B 84 00 A4 95 00 58 C0 B1 00 D4 DA 62 54 00 0E 12 60 EE 00
Healthy: 12 06 CD 10 1B 84 00 A4 95 00 58 C0 B1 00 D0 D1 65 52 1B 30 12 60 EE 00
^^^^^^^^^^^^^^^^^
REG_0Eh .. REG_13h
The two parts are identical on every single register except the six ADC results.
In particular, on the faulty unit:
-
REG_0Dh = 0x00— no fault of any kind reported -
REG_17h = 0x00— safety timer not expired -
REG_0Ch = 0xB1— VIN_STAT = 5, CHG_STAT = 2, i.e. the part reports a constant-current charge in progress -
REG_12h = 0x00— while ICHG reads zero
3.2 Repeated conversions
Same one-shot sequence as in section 2, issued by hand, several seconds apart.
Faulty unit, every attempt over several hours, across firmware reboots:
vbat 0xD4, vsys 0xDA, ntc 0x62, vin 0x54, ichg 0x00, iin 0x0E
vbat 0xD4, vsys 0xDA, ntc 0x62, vin 0x54, ichg 0x00, iin 0x0E
vbat 0xD4, vsys 0xDA, ntc 0x62, vin 0x54, ichg 0x00, iin 0x0E
Healthy unit, three consecutive conversions:
vbat 0xD0, vsys 0xD1, ntc 0x65, vin 0x51, ichg 0x1B, iin 0x2E
vbat 0xD0, vsys 0xD1, ntc 0x65, vin 0x52, ichg 0x1A, iin 0x2F
vbat 0xD0, vsys 0xD1, ntc 0x65, vin 0x51, ichg 0x1B, iin 0x2D
The faulty unit decodes to VIN = 5.04 V and IIN = 0.186 A. Two separate observations show these are not live measurements. First, the same six bytes were already present in a register dump taken before the firmware had requested a single conversion. Second, VIN keeps reading 5.04 V with the USB input physically disconnected, indefinitely. They describe a state the part was in at some unknown point in the past. Because REG_0Eh to REG_13h are marked Reset by REG_RST = N, they survive the host’s device reset and are therefore indistinguishable from a live measurement to any software reading them.
3.3 Register write integrity, faulty unit
Every write lands and reads back as expected, including bits that are documented to behave specially:
| Write | Reads back | Comment |
|---|---|---|
| REG_08h ← 0x40 | 0x40 | EN_ADC_DSG sets and holds |
| REG_08h ← 0xDD | 0xD5 | only bit[3] WATCHDOG_TIMER_RESET clears, as documented; identical on the healthy unit |
| REG_03h ← 0xD0 | 0x50 | ADC_RATE latches; ADC_START reads 0, identical on the healthy unit |
| REG_0Ah ← 0x5B | 0x5B | |
| REG_02h ← 0x4D | 0x4D | |
| REG_01h ← 0x80 | 0x06 | REG_RST self-clears and POR defaults are restored, see 3.4 |
3.4 Recovery attempts, all ineffective on the faulty unit
| Attempt | How | Result |
|---|---|---|
REG_RST |
REG_01h ← 0x80, charger task frozen | REG_00h and REG_02h returned to POR defaults, confirming the reset executed. ADC results unchanged. |
| Watchdog expiry | host stopped servicing the watchdog | REG_0Dh bit[7] WATCHDOG_FAULT set, WTD-resettable registers returned to POR defaults. ADC results unchanged. Observed twice. |
BG_EN cycle |
REG_09h bit[3] 1 then 0, 20 ms apart, 3 times, 30 s apart | ADC results unchanged |
| Continuous mode | REG_08h = 0xDD then REG_03h = 0xD0; EN_ADC_DSG verified still 1 by readback (0xD5) 4 s later, ADC_RATE verified latched (REG_03h = 0x50) |
ADC results unchanged after several seconds |
| NTC re-enabled | REG_02h bit[4] EN_CHG_NTC set |
ADC results unchanged |
| Input removed and reapplied | USB unplugged, several minutes, replugged | ADC results unchanged |
| Battery physically disconnected, input also removed | enclosure opened | ADC converts normally again |
3.5 BATTFET_DIS is also inert on the faulty unit
This is our second, independent observation of a register that accepts a command without any physical effect.
Preparation, identical on both units:
REG_08h ← 0x85 watchdog disabled, so nothing resets the configuration below
REG_02h ← 0x4D tSM_DLY = 0, no shipping-mode entry delay
REG_0Ah ← 0x5C BATTFET_DIS = 0, SYSRST_SEL = 1, tDISC_H = 11
Then, with the input removed, the host wrote REG_0Ah ← 0x7C (BATTFET_DIS = 1).
| Faulty unit | Healthy unit | |
|---|---|---|
REG_0Ah readback after the write |
0x7C, bit[5] set | not captured — see note |
| System behaviour | stayed powered from the battery for 60 s | powered down immediately |
Note on the healthy unit: the console shares the USB connector with the charger input, so the readback could not be captured after the input was removed. The system powering down is itself the evidence that the write landed and the BATTFET opened. On the next plug, the unit came back up normally and REG_0Ah read 0x58 again, the host having rewritten it at boot.
We also confirmed that the write is correctly refused while an input is present, on both units: REG_0Ah ← 0x78 reads back 0x58, while bits[1:0] of that same write do land. We assume this is intended behaviour, and all comparisons above were therefore made with no input on both units.
4. What we conclude, and what we cannot explain
The digital side of the part is healthy. The register file, the I2C interface, the self-clearing bits, the reset logic and the POR default restoration all behave exactly as the healthy reference unit.
Two independent functions that reach into the analog domain — the ADC, and the BATTFET disconnect — accept their commands and produce no physical effect. The part reports no fault while this is true, and even reports a constant-current charge in progress.
We cannot explain what internal state causes this, why it survives REG_RST and a watchdog reset, or why only a full removal of supply clears it.
The affected units come from more than one production batch. That argues against a lot-specific defect and points at something in the way the application uses the part — see the ADC duty cycle in section 2.
5. Questions
-
Is this a known failure mode of the MP2733? Is there an errata?
-
What internal condition can stop the ADC converting while leaving the I2C interface and the whole register file fully functional and fault-free?
-
Is there any I2C-reachable sequence that resets the analog domain of the part, short of removing its supply? We have tried
REG_RST, a watchdog expiry, aBG_ENcycle andBATTFET_DIS, and none of them work. -
Does the fact that
BATTFET_DISis also inert indicate the same root cause, or is that a separate failure? -
Is our ADC duty cycle — one-shot conversion every 200 ms with
EN_ADC_DSGtoggled 1 → 0 each time, continuously for weeks — within the intended use of the part? Would continuous mode (ADC_RATE= 1) withEN_ADC_DSGleft set be gentler, or a lower polling rate? Is there a recommended maximum? -
Does continuous powering without ever going through a POR contribute to this? Is any periodic maintenance recommended for a product whose battery is never disconnected?
-
For a sealed product with a non-removable battery, is there a recommended hardware provision to force a POR of the MP2733? Our understanding is that the DISC pin drives the same BATTFET that is already inert on the affected parts, so it would not help. Is that correct?
We have the affected units in hand and can run any additional register sequence you would like measured.