IP2366 I2C Register Map

This reference consolidates the supplied Chinese V1.00, English V1.13, Chinese V1.14 and Chinese V1.16 register manuals. It is a best-effort and work in progress, not a replacement for matching the document to the actual IP2366_I2C chip/firmware variant:

• Use entirely at own risk. Documented fields, translation disagreements and experimental interpretations are distinguished below. A successful read or bus ACK does not establish safe write behavior.
• Add your own findings or corrections by leaving a comment below.

Primary documents used in this revision

Page numbers below are PDF page numbers, starting at 1. They are not firmware version numbers. The earlier three-document review checked the connection diagram, transaction diagrams and disputed PDO tables visually. This revision adds the complete V1.16 register text and checks its newly defined fields against the existing reference. V1.16 prints an obsolete total of 18 pages in its footer, but the supplied PDF actually has 22 pages; use the PDF page numbers below.

Use Ambiguities and DUT validation before choosing a revision-sensitive decoder or writing a setting. Other source IDs refer to the historical implementation resources in the source index; they were not re-audited as part of the original three-document comparison. Source O is the primary reference for the additional fields in this revision. The supplied PY32 display firmware was also inspected as implementation evidence, not as a replacement for the manufacturer contract or proof that it matches the installed factory binary.

Reading this map

• All register addresses are hexadecimal, byte-wide addresses unless shown as a low/high pair.
• k is the numeric register field; S is the physical/configured series-cell count. This avoids the manuals’ ambiguous reuse of N for both.
• R/W means documented read/write. R means documented read-only. W1C? marks a text/table inconsistency concerning write-one-to-clear.
• Reset values below describe fields, not a byte to write blindly. Reserved bits must be preserved. Read actual power-up values; defaults can vary.
• A/B identifies the original baseline comparison; N also agrees unless a difference is called out. B/N identifies additions absent from A. O identifies the supplied V1.16 manufacturer document; old evidence labels are retained unless explicitly extended. lead means an incomplete or unverified definition, not an implemented register contract.
• Boolean flags are shown as 0/1 with their specific meaning. A single-bit selector such as 20/80 microamperes or 2.4/3 A is a value selection, not a generic true/false flag.
• Extract a field with k = (byte & mask) >> shift. Convert once into the stated unit. A representable code range is not necessarily a supported configuration range or a measurement-accuracy guarantee.
• Unless a row explicitly lists reserved bits, all unlisted bits are reserved or undocumented. An unlisted address is not necessarily nonexistent.

Communication requirements

Pins and connection diagram

A p.2 and N p.2 show the following IP2366_I2C package-pin assignments. These are IC pin numbers, not header numbers on a charger module. Map the actual PCB before connecting; do not confuse high-current power pins with logic signals.

The text specifies a 3.3 V communication level. The drawing labels the pull-up rail VCCIO; it is not permission to connect the bus to battery voltage, VBUS or 5 V. The 2.2 kohm values are the application example, not a universal requirement for every bus. A passive sniffer normally uses the DUT’s existing pull-ups and does not drive SDA/SCL. INT is driven by the chip after wake and becomes an input before sleep; its complete output-drive specification is not supplied here, so do not prescribe an MCU push-pull-high connection solely from the wake text.

Single-register transfers

The diagrams in A p.3, B p.2 and N p.3 use this sequence. ACK is driven by the receiver; the host deliberately NACKs the final read byte. Bytes below are on-wire values, not API addresses:

Read register r:
START -> EA -> ACK -> r -> ACK -> repeated START -> EB -> ACK -> data -> host NACK -> STOP

Write register r:
START -> EA -> ACK -> r -> ACK -> data -> ACK -> STOP

The waveform annotations show 50 microsecond preparation pauses after the write address ACK, after the register-selector ACK, and after the read-address ACK. The write diagram also shows a pause after the selector ACK. Implement these as physical bus gaps; sleeping while filling a software transmit buffer does not necessarily delay anything on the bus. The prose additionally recommends single-byte reads at 100 kHz and 1 ms between bytes; the exact applicability of that recommendation to separate complete transactions versus a burst is not fully specified. No guaranteed automatic register-increment/burst contract is given. A slow clock by itself is not proof that the illustrated inter-byte gaps are present.

The example writing 0x5A to 0x05 demonstrates the frame format only. None of the four supplied register lists defines 0x05; do not reproduce that write on a DUT. The demonstrated real read from 0x31 returns 0x22 in the example capture; this is an example observation, not its reset value.

For ordinary documented R/W fields, preserve unrelated bits with new_byte = (old_byte & ~mask) | ((k << shift) & mask), checking that k fits the supported codebook. This is not a generic recipe for W1C, reset or one-shot command bits: copying a latched 1 back into a W1C field can clear another event. Stop on an address/data NACK; do not interpret missing data as a zero value.

System and charging controls

Theoretical BAT CV windows, assuming the selected cell count is actually active and charger operation allows the requested voltage:

These are register arithmetic, not verified continuous bench-supply operating ranges. They do not demonstrate startup into zero volts, absence of termination, accuracy, or stability.

USB-C role and source PDO controls

For custom current settings, the manual describes output overcurrent protection at about 1.1 times the configured PDO current for the listed higher-voltage/PPS fields. This is not equivalent to a tightly regulated lab CC setpoint. Changing source advertisements may also require renegotiation; no universal live-update sequence was established.

None of the four supplied maps exposes a 28 V source-PDO current/enable field, AVS voltage request, or PPS minimum/maximum-voltage field. The 28 V input category in A/N’s status register does not imply a corresponding writable source PDO. The broader chip family supports EPR according to F, but that does not fill these register-map gaps. B p.4 additionally says that more than 60 W requires an E-marker recognition circuit; its 20 V/PPS prose requires recognized cable capability for 5 A and otherwise limits to 3 A. These B-only constraints should not be treated as permission to exceed the board/cable rating.

Conflicting 0x0D[2:0] input-PDO codebooks

Do not confuse these selection codes with the independent 0x33 input-voltage status codes. 0x35 reports offered PDO availability, not the chosen contract or measured voltage. O p.8 now explicitly marks 0x0D[2:0] R/W, resolving that access discrepancy for its documented variant. It agrees with N on codes 0-5 and additionally describes nearest-lower-voltage fallback. The older B/N access-column conflict remains relevant when identifying older variants.

Corrected DUT observations (2026-10-09): 0x0D consistently reads 0, including with a PD supply negotiating 20 V. The earlier reported value 7 was the displayed mask 0x07, not the register value, and is withdrawn. Code 0 with 20 V input supports N’s automatic-selection interpretation, rather than B’s 0 = 5 V. The working YAML uses 0 automatic, 1-5 = 5/9/12/15/20 V, with 6 and 7 undefined. Codes 1-5 and write access remain untested. A 28 V-capable PD 3.1 supply did not yield 28 V charging input in this setup; this is an observation, not an established universal input limit.

Separately, connecting a known 20 V PD input changed 0x33[2:0] from 0 to 6. This confirms code 6 = 20 V on this DUT, supporting A/N and contradicting B’s code-6 = 15 V entry. Other voltage-category codes remain untested; the preceding code 0 is only an observed pre-connection state, not an established voltage. Read-only exploration and passive captures should come before any controlled write test of this field. O p.15 independently documents the A/N codebook for 0x33[2:0]; it does not make code 0 a valid voltage category.

Status and partner capabilities

0x38 describes repeated fault detections within roughly 600 ms and approximately 1.5 s before sleep. B’s fault-recovery prose refers to toggling 0x22[7], but its own map defines 0x22[7:6] as the Type-C role. Treat that recovery instruction as suspect; do not implement it blindly.

Conflicting 0x33[2:0] codebooks

Use measured 0x52/0x53 voltage and known adapter profiles to identify the codebook your chip uses. A higher document version number does not prove it matches your chip or that every entry is correct.

Measurements and identification bytes

Read pairs in separate explicit statements so language expression-evaluation order cannot reverse them. Decode direction from validated operating state; the DUT current values are positive magnitudes in both directions and must not be reinterpreted as signed currents. NTC voltage plus excitation current can yield resistance; converting that to temperature requires the actual thermistor curve and board network.

Conversion examples and measurement limits

For each documented pair, assemble raw16 = low | (high << 8) after reading low first. The manuals state that a low-byte read refreshes the corresponding low and high bytes. They do not define one atomic snapshot spanning battery voltage, battery current, system voltage, system current and power. Do not present values collected at different times as simultaneous without that qualification.

If the actual board applies the indicated excitation current entirely through a thermistor, resistance_ohm = 1000 * ntc_voltage_mV / excitation_current_uA. Parallel resistors, clamps, leakage and current-source compliance can invalidate that simple calculation. The I2C manuals provide no thermistor beta/Steinhart-Hart coefficients, ADC accuracy, sample rate, signed-current encoding or die-temperature calibration. They do not define SMBus PEC, SMBus block protocols or a device-ID command; use the documented I2C register transfers rather than assuming SMBus semantics from the electrical bus.

Defined-bit index

These masks summarize the four supplied manuals, with O additions explicitly identified. They are defined-field masks, not write permissions or complete reset bytes. Preserve the complement for ordinary R/W changes; use the field access and special command semantics above. A defined bit in V1.16 must not be assumed writable on a different chip/firmware variant. Earlier masks remain useful only for the earlier documents they describe.

For multi-field bytes, reset codes must be shifted into their own fields. For example, 0x08’s termination code 2 and recharge code 2 contribute (2 << 4) | (2 << 2) = 0x28 under mask 0xFC; they do not mean writing byte 0x02. Under O the complete defined mask is 0xFE, but adding bit 1 to a write policy requires an explicit completion/timeout decision; it is not merely a formatting update to the old mask. Read actual values and preserve reserved bits. Blank reset cells and X mean unspecified, not zero. Reserved cells printed R/W in Chinese copies or R in B still must not be modified.

Undocumented or questionable address leads

These rows are intentionally separated from the documented map. They are not permission to write these locations, and names alone do not determine whether they are configuration commands, raw GPIO ADC readings, or copied definitions for another chip.

D also calls 0x35 MOS_STATE, conflicting with B/N’s RECEIVED_PDO and the historical C decoder. Together with the GPIO labels, this reduces confidence in its unexercised header definitions. A candidate address is evidence worth investigating, not a verified extension of the manufacturer map.

Ambiguities and DUT validation

Consolidated DUT results (2026-10-09)

Measurements below were independently compared unless stated otherwise. These results determine the working YAML interpretation; historical manual conflicts are retained for readers dealing with other revisions. Source O now documents 0x04, 0x17 and 0x3A and confirms the working voltage-status/PDO codebooks; the rows below retain their original experiment dates, not new bench testing. Reset defaults, physical trip accuracy and write/recovery mechanisms are separate from read decoding.

Historical conflicts and remaining tests

This historical working list is retained with V1.16 resolution notes below. D03/D10 access/codebook and D15 documentation gaps are resolved by O for its documented variant; D09 now also requires checking separate input-power fields. They are not all still-open manufacturer-definition questions. Contradictions are different statements in the supplied manuals. Gaps are information none of the manuals establishes. A revision difference is not automatically an error, and two agreeing documents do not prove the DUT uses their codebook.

Prioritize read-only/passive observations. Do not create a short circuit, overcurrent, undervoltage, overtemperature or unsafe charge setting merely to resolve a documentation gap. Any later write experiment needs its own protected setup, confirmed register semantics and recovery plan; this table is not a set of authorized write instructions.

Record each experiment with chip marking, PCB identity, known cell count, adapter and cable, existing-controller firmware, raw transactions, before/after state, independent measurement and any capture-loss indication. A result should be labelled confirmed on this DUT, not silently promoted to a universal IP2366 definition. Several tests can settle a decoder’s behavior without enabling any configuration writes.

Revision history and incompatibilities

The following is the Chinese document history through O p.1, cross-checked with A p.1 and N p.1. B p.12 has misaligned/mistranslated history wording, including the V1.00 wake text and the V1.11 power/battery-level wording. These dates describe documents, not proven silicon or firmware release dates.

F lists B, C, and D silicon/firmware families. ENP and STB variants differ in wake behavior and standby consumption; C variants require charging activation, and F recommends migration to D. It explicitly requires matching chip and firmware versions. Package markings such as your “993 00DY” and “323 00DY” were not reliably decoded by the sources inspected, so neither marking proves this map’s applicability.

The repository also contains IP2368 V1.61/V1.63 documents. They are not IP2366 register revisions. Similar names do not justify importing IP2368-only controls into this map.

Focused follow-up: register 0x01 (2026-10-05)

The initial 0x01 lead does not survive source inspection as evidence of a working IP2366 cell-count command. The Byoreh_94 STM32 header defines the address, but the posted implementation has no read/write call using that definition. Its initialization only configures GPIOs; its data-reading state machine polls status and ADC values. A generic WriteOneByte helper is present, but no concrete 0x01 invocation is shown.

The wording “series number setting, battery type, current setting mode” matches the IP2368 SYS_CTL1 heading. That IP2368 document nevertheless lists upper bits as reserved and only four chemistry/mode fields. Copying that heading is a plausible explanation for the IP2366 header comment; its provenance is not proved.

Most complete bit definition found: IP2368 only

This is a comparison, not an IP2366 map.

GitHub projects and implementation resources

Source index

Links below are ordinary public URLs. “Inspected” means the document or code was actually retrieved and read; “lead” means availability or attached content was not verified.

The inspected GitHub snapshot is commit 9a23b86ec0f2544c56b25e16900b5257347a150a. For reproducibility, replace main in GitHub links with this commit. No exhaustive claim is made about private customer manuals, QQ group files, unindexed repositories, or chip-specific customized firmware.

Passive decoding clarifications (2026-10-07)

V1.16 update (2026-10-21): the historical headings below retain their original anchors. Manufacturer definitions in O now replace INFERRED labels for 0x04, 0x17 and 0x3A on its documented variant. Original observations and untested physical behavior remain separate evidence.

The following additions distinguish a register-map interpretation from a verified physical measurement. They were recorded while deriving a YAML profile and a PC-side interpreter for passive I2C recordings. They do not authorize active queries, configuration writes, or protection/control decisions.

Assembling measurements from separate transactions

A normal I2C transaction does not identify the physical width or meaning of a register. The low/high grouping, byte order and scale come from this map, not from the signal itself. For the documented pairs, source A page 11 requires low before high because reading low refreshes both bytes. A pointer-selection write followed by a repeated START and a read is part of a register read; it is not a write of the returned measurement.

For a conservative passive decoder, combine only successful single-byte reads of the specified low and high registers, in that order, with no intervening transaction to the same device. Invalidate a pending pair after a failed transfer, capture/output loss, capture pause/reset, reconnect, or an unexpected target transaction. This adjacency rule is a decoder policy, not an additional chip timing requirement. Other-device traffic does not by itself invalidate the documented latch, but any reported capture loss does.

Without capture timestamps, ordered USB lines cannot establish a precise acquisition-time interval. Host arrival times are not bus timestamps. Separate reads are the baseline here; do not assume that a multi-byte read automatically increments the register pointer merely because I2C permits multiple data bytes. An explicit device-specific burst contract is needed before interpreting one.

Remaining interpretation boundaries

Newly recorded primary-source lead: 0x56/0x57

Source A page 14 contains an isolated sentence that discharge current is stored in 0x56 and 0x57, referring to 0x31[3] as a discharge indicator. However, the inspected map provides no corresponding complete register entries establishing width, scale, signedness, latch behavior, or applicability. This conflicts with the temptation to treat the sentence as a complete alternative current accessor. It is an unresolved lead only: no physical-value decoder for these addresses is enabled. Confirm against a matching manufacturer revision and bench readings before adding an interpretation.

The supplied V1.14 manual N p.15 and English B p.10 omit this sentence. Its absence does not prove the registers were removed, but it leaves the V1.00 lead without a complete definition in any of the supplied revisions.

Bench-supported inference: 0x04 series-cell count

On 2026-10-07, passive capture of the user’s IP2366 operating with a known 4S battery returned 0x04 from register 0x04. Together with similar-chip register documentation (specific document/revision not supplied), this supports the working interpretation Bat_Num = register & 0x07, in units of series-connected cells. The proposed valid range is 2-6; codes 0, 1 and 7 are outside that inferred range, but their actual hardware meaning has not been established.

On 2026-10-09 the user experimentally confirmed that changing the series-cell setting changes this field to the corresponding cell count. Direct encoding is therefore the working interpretation, not merely a single 4S correlation. The tested counts were not individually enumerated. Power-up behavior, interaction with BAT_NUM hardware and wider variant applicability remain unspecified. Bits 7:3 are preserved. O p.5 now explicitly documents bits 2:0 as direct cell count 2-6 and bits 7:3 as reserved; the earlier inference is confirmed by primary documentation, not an inference that all variants behave identically.

Bench-supported inferences: 0x17 and 0x3A

The user supplied the following working definitions on 2026-10-07, based on similar-chip documentation and passive sniffing. No matching primary IP2366 register document or specific similar-chip revision was supplied.

The subsequent full review of A, B and N on 2026-10-09 still found no entries for these addresses. The subsequent V1.16 review (2026-10-21) changes that status: O p.9 documents 0x17, and O p.17 documents 0x3A. Read their current definitions in the main tables above; the observations below retain their historical context and do not establish physical accuracy or trip performance.

• 0x17[7] is NTC_EN: 1 means battery NTC temperature protection enabled, 0 disabled. On 2026-10-09 the DUT setting comparison confirmed enabled = 0x80, disabled = 0x00. Bits 6:0 are preserved; field polarity is verified, but this comparison is not a test of protection-trip behavior.
• 0x3A[6:0] is an inferred unsigned, direct internal die temperature in degrees Celsius, with 0x3A[7] indicating thermal-loop activity. A captured byte 0x1E gives code 30 and an inactive-loop bit. The 30 degrees Celsius interpretation is plausible near room temperature/light load, but was not independently calibrated. On 2026-10-09 the user reported experimental verification that bit 7 indicates active internal thermal regulation. Accuracy, negative-temperature encoding and wider-range validation remain unspecified. O p.9 now documents the nominal configurable thermal threshold in 0x10[2:0], but not trip accuracy. Codes 0-127 are the representable field range, not a verified operating/accuracy range.

The user later confirmed that the reported internal temperature rises plausibly as the board warms during battery charging. This strengthens the temperature interpretation but is not an independent calibration. The reading remains valid when the thermal-loop flag is 0: a protection/loop-status bit is not an ADC-valid bit. Active per-property and batch reads have also been reported working on this DUT through the test instrument; that confirms acquisition on this setup, not universal read side-effect freedom or write access.

These are separate properties: the internal die reading and thermal loop must not be presented as the battery thermistor temperature or proof that battery NTC protection works. For an O-matched variant these fields can now be labelled manufacturer-documented; retain any separate DUT applicability/calibration caveats. Historical passive observations alone do not establish safe write or protection behavior.

Charger integration and host-source findings (2026-10-21)

For the O low-voltage formula, distinguish the base code k_base, adjustment code k_adjust and cell count S: base_cell_mV = 2500 + 100 * k_base, adjust_cell_mV = 100 * k_adjust, and the stated pack threshold is S * (base_cell_mV +/- adjust_cell_mV), with the sign chosen by 0x0A[4]. For example, base code 5, adjustment code 1 and subtraction give a nominal 2900 mV per cell rather than 3000 mV. This is a mathematical cross-check of the documented formula, not a recommendation to configure that combination or proof of its physical trip point. O reuses N for two different quantities; the separate variable names here avoid confusing adjustment code with cell count.

V1.16 adds controls that an older driver can silently inherit while preserving unrelated bits. A read-only audit should distinguish requested settings from their effective interpretation:

The supplied 1.47-inch PY32 host project contains active direct IP2366 register reads despite filenames and symbols named SW6236. It confirms an implementation using low/high voltage/current reads and 10 * raw16 mW power conversion. It also contains old SW6236 unlock/gateway/low-current helpers, some disabled or returning failure; those are not an IP2366 write-unlock or current-ramp contract. No documented soft-start/ramp-rate adjustment was found in V1.16 or the active charger-setting paths inspected.

Its Battery Series menu changes local SOC/display state rather than writing 0x04. Output Enable writes discharge enable 0x0B[7], not charging enable 0x00[0]. Its IP2366 external-NTC temperature is stored in a misleadingly named chip_temp_c10 field; it does not read die register 0x3A. A separate local PUYA ADC thermistor controls the fan. The source table is labelled 10 kohm/beta 3950, which is implementation evidence, not a verified thermistor specification for every board. This distinction matters when replacing the original host.

The source also tolerates stale measurements after some read failures and has display-sleep paths that suspend normal supervision. These are implementation limitations to correct in a charger, not device requirements to copy. Source provenance as the exact installed factory binary has not been established.

Change record

• 2026-10-21: incorporated supplied manufacturer register document V1.16 and V1.15/V1.16 history. Promoted cell count, NTC enable and die-temperature fields from inference to documented definitions for the matching variant.
• 2026-10-21: added completion/timeout policy, low-voltage adjustment, separate input-power limit, thermal controls, D-revision standby mode, CC3/CC4 drive, standby delay, anti-EMI bit, received 28 V/partner flags and IC revision.

• 2026-10-21: updated defined-bit masks and PDO selection access/fallback; retained earlier revision conflicts, actual DUT results, unresolved W1C behavior and variant/accuracy limits. Added source-code integration caveats.

• 2026-10-09: consolidated independent DUT current/power measurements, newer low-voltage encoding, input/output power scope, NTC/cell-count/thermal-loop confirmations and 100-1000 mA working trickle range. Corrected PDO readback from the mistaken mask 7 to actual value 0; identifier observed as YLSII.

• 2026-10-09: compared all three supplied manuals, including visual inspection of connection/transaction diagrams and conflicting PDO tables. Identified the unversioned Chinese file as V1.14; added source/page provenance, IC pin wiring, preparation gaps, register-transfer examples and the warning that example register 0x05 is not defined in the map.
• 2026-10-09: added V1.14’s 100 mA trickle-current minimum, B/N PDO-selection conflict, A/N versus B voltage-status and role-default differences, and explicit distinction between read access and disputed write permission at 0x0D.
• 2026-10-09: corrected ASCII-register provenance and power-register R access; confirmed 10 mW/code from both Chinese manuals, retained B’s omitted scale and corrected the battery-level/power revision-history interpretation.
• 2026-10-09: added all documented register masks, conversion examples, unspecified-contract boundaries and the D01-D16 DUT validation list. Preserved all earlier experimental findings and separated them from manufacturer fields.

• 2026-10-09: recorded the user-confirmed die-temperature warming trend without claiming accuracy, calibration, active thermal-loop validation or write safety.

• 2026-10-07: added passive assembly policy and clarified that host arrival timing is not acquisition timing; no new chip timing requirement was inferred.
• 2026-10-07: cross-checked A’s low/high latch rule, measurement units, NTC excitation and PDO add bits. Existing A/B conflicts were retained, not resolved.
• 2026-10-07: recorded the previously unlisted 0x56/0x57 sentence as an incomplete primary-source lead, not a verified register-map extension.
• 2026-10-07: added inferred 0x04[2:0] Bat_Num decoding with a 4S/code-4 bench observation; retained the earlier capacity label as a conflicting lead.
• 2026-10-07: added inferred 0x17[7] NTC protection enable and read-only 0x3A die-temperature/thermal-loop fields; recorded the 0x1E observation without claiming independent temperature calibration or active-bit validation.
• Consolidated DUT results above supersede earlier open current-signedness and working-codebook questions. Direction attribution, variant applicability, unknown-register leads, burst semantics and write-access contradictions remain separate limitations.

Materials

• IP2366 I2C Register Reference 1.16 (Chinese, latest supplied; 2025-04-28)
• IP2366 Datasheet
• IP2366 I2C Register Reference 1.13 (English; compare disputed entries with Chinese originals)
• IP2366 I2C Register Reference 1.14 (Chinese; 2023-10-27)
• IP2366 I2C Register Reference 1.0 (2023-03-24)

Slow Website?

This website is very fast, and pages should appear instantly. If this site is slow for you, then your routing may be messed up, and this issue does not only affect done.land, but potentially a few other websites and downloads as well. Here are simple steps to speed up your Internet experience and fix issues with slow websites and downloads..

Comments

Please do leave comments below. I am using utteran.ce, an open-source and ad-free light-weight commenting system.

  Show on Github    Submit Issue

^{_{(content created Oct 05, 2026 - last updated Oct 21, 2026)}}