CD3217 ACE-ROM Power-On Sequence and USB-C Diagnosis
CD3217 / ACE2 USB-C and ACE-ROM power-on sequence
Last updated: 16 August 2026
This subpage explains how a CD3217 USB-C/ACE controller starts an Apple-silicon MacBook from a charger with the battery disconnected. The principal measured example is the 14-inch M1 Pro MacBook Pro A2442 logic board 820-02098.
The important correction: basic CC1/CC2 attach does not wait for the external ACE-ROM. Hardware dead-battery Rd must already be visible so the USB-C source will provide its initial 5V. The external ACE-ROM patch and configuration are then loaded before the controller reaches the normal Apple-configured application state and the later 20V USB-PD negotiation.
Return to the A2442 820-02098 M1 Pro master power-on sequence, or see our Apple-silicon logic-board repair case studies.
Table of Contents
CD3215, CD3217, ACE and SN25A12: use comparisons, not equals signs
Apple markings do not have public Apple or Texas Instruments cross-reference documents. Public TI datasheets are extremely useful for understanding the architecture, but they do not prove that an Apple-marked controller is electrically or firmware-identical to a retail TI part.
| Apple marking or name | Useful public architecture reference | How it should be described |
|---|---|---|
| CD3215 / CD3215C | TPS65982 and earlier TPS6598x family | Closely related repair reference; do not state that the two part numbers are officially identical. |
| CD3217 | TPS65983B plus later TPS6598x boot concepts | Apple-custom USB-C/PD controller used on boards including A2442/820-02098. TPS65983B is a useful functional reference, not a confirmed exact identity. |
| ACE / ACE2 | TPS65987D/TPS65988 architecture and boot reports | Apple platform terminology. Public TI material helps explain LDO, boot ROM, SPI patch/config loading, CC/PD and managed power paths. |
| SN25A12 / ACE3 | No public one-to-one datasheet | Newer Apple-custom generation seen on newer designs. Diagnose from the board schematic and measurements rather than assigning an unverified retail TI number. |
Terminology used in this guide
The USB-C connector terms describe the standard Type-C interface. The PP-prefixed names are Apple logic-board net names. Keeping those two naming systems separate makes the power path much easier to follow.
USB-C attachment and power terms
| Term | Plain-language meaning | Why it matters during diagnosis |
|---|---|---|
| USB-C source | The device supplying power—normally the charger. | It presents Rp on the CC pins and enables VBUS after detecting a valid sink. |
| USB-C sink | The device receiving power—in this guide, the MacBook logic board. | It presents Rd so the charger knows that a power-consuming device is attached. |
| CC1 / CC2 | The two Configuration Channel pins in a reversible USB-C connector. They are not a differential data pair. | Cable orientation decides which CC pin becomes active. USB-PD BMC messages normally travel on that one active CC wire; the other may be unused or provide VCONN depending on the cable. |
| Rp | The source-side pull-up resistance or current advertisement on CC1/CC2. | The charger uses Rp to identify itself as a source and advertise default Type-C current capability. |
| Rd | The sink-side pull-down resistance on CC1/CC2. | The charger must detect Rd before it supplies the initial default VBUS. |
| Dead-battery Rd | A hardware-presented Rd that remains available while the MacBook and controller firmware are unpowered. | It allows an empty-battery or battery-disconnected board to obtain the first 5V. Its presence does not prove that ACE-ROM loaded. |
| VBUS | The main USB-C power conductor at the connector. | It normally begins near 5V and can later change to 9V, 15V or 20V after USB-PD negotiation. On this A2442 capture it changes from 5V to 20V. |
| BMC | Biphase Mark Coding, the electrical encoding used for USB-PD packets on the active CC wire. | Visible BMC bursts show that more than a static CC voltage is present, but the messages must still be decoded or compared with a known-good capture. |
| USB-PD contract | The agreed voltage/current relationship formed by messages such as Source Capabilities, Request, Accept and PS_RDY. | The initial 5V attach is not the same checkpoint as the later negotiated 20V contract. |
| PDO | Power Data Object: one voltage/current option offered by the charger. | The MacBook selects an acceptable PDO when requesting the higher-voltage contract. |
| PS_RDY | “Power Supply Ready,” a USB-PD message confirming that the source has completed the requested power change. | It separates a completed high-voltage transition from a request that was sent but never fulfilled. |
Controller, firmware and Apple board-net terms
| Term | Meaning on this A2442/820-02098 reference | Diagnostic interpretation |
|---|---|---|
| PPVBUS_USBC0 | The charger-side USB-C VBUS rail before the CD3217 managed power path. | Approximately 5V here proves that the charger supplied default VBUS; it does not prove that power passed through CD3217. |
| LDO | Low-dropout regulator. CD3217 uses its VBUS-powered internal LDO to create PP3V3_UPC0_LDO. | The 3.3V LDO powers controller boot domains and the external ROM. LDO present does not prove a successful ROM read. |
| Internal boot ROM / mask ROM | Code permanently built into the controller silicon that runs immediately after power-on reset. | It initializes the controller, reads boot straps and starts the external patch/configuration loading process. |
| ACE-ROM | The external SPI flash containing Apple-specific patch code and configuration for the port controller. | A valid supply and SPI transaction are required. Treat it as patch/configuration storage—not as the controller’s entire brain. |
| SPI | Serial Peripheral Interface using CLK, CS_L, MOSI and MISO; WP_L and HOLD_L also affect the flash. | Clock and chip-select prove an attempted access; meaningful MISO data and correct downstream behaviour provide stronger evidence of a valid load. |
| FET / internal power path | The controller-managed MOSFET path connecting connector-side VBUS to the system-side high-voltage input. | It can pass the default 5V before the later 20V contract. Protection, configuration or hardware faults can keep it off. |
| PP_HV | The controller’s managed high-voltage system-side power-path node. | It should follow the accepted VBUS condition when the path is enabled. Exact naming and placement vary by board. |
| PPDCIN_AON | The always-on adapter-input rail reaching the A2442 charger circuit after the USB-C controller/input path. | About 5V proves the early managed path is conducting; about 20V later confirms successful high-voltage negotiation and delivery. |
| I2C_SMC_UPC_SDA | The data line used by the embedded SMC/SoC domain to communicate with the USB-C port controller. | Its activity is a later system checkpoint and should not be expected merely because the controller LDO or SPI-ROM activity is present. |
Does CC1/CC2 communication happen after ACE-ROM loading?
Correct answer: partly.
Passive dead-battery Rd, basic source detection and initial 5V VBUS happen before the external ACE-ROM patch/config is loaded. Normal Apple-configured USB-PD policy—including the meaningful BMC message exchange that later requests 20V—occurs after a valid configuration has been loaded and the controller reaches application mode.
A USB-C source does not simply apply VBUS before seeing a sink. It presents Rp on CC1/CC2, detects Rd on the connected CC wire, and then enables default 5V VBUS. TI documents hardware-configurable dead-battery Rd specifically so an unpowered sink can obtain this first 5V supply.
After VBUS powers the controller, its internal boot code runs and attempts to load the external patch/configuration. The external flash is therefore not literally the controller’s entire “brain”: TI’s comparable controllers contain internal boot and application ROM and use external flash for configuration and code patches. If the external image is missing or invalid, behaviour depends on the boot straps and safe/default configuration; PD may be disabled, the power path may remain off, or a limited safe power path may operate.
Sources: TI TPS65983B datasheet, TI TPS65987/88 boot-flow report, and TI TPS65987/88 hardware design guide.
CD3217/ACE2 power-on sequence overview
CD3217/ACE2 power-on sequence measured on an A2442 board 820-02098, showing passive CC attach, internal LDO and boot ROM, external ACE-ROM read, 5V power-path enable, SMC communication and the later 20V USB-PD contract.
Stage 0 — Hardware dead-battery Rd before VBUS
With the board unpowered, the controller cannot first run firmware and then ask the charger for power. The port instead relies on a hardware dead-battery configuration that presents Rd on CC1 and CC2. When the charger presents Rp, one CC wire becomes the active orientation channel.
This is why seeing an appropriate CC idle voltage or receiving initial 5V does not prove that the ACE-ROM has been read. It proves that the source detected a sink-level attach condition.
Stage 1 — The charger applies default 5V VBUS
After detecting Rd, the charger enables approximately 5V at the connector. On A2442/820-02098, this is measured as PPVBUS_USBC0 before the CD3217 managed internal power path. There is no high-voltage PD contract at this point.
If there is no 5V at the connector, begin with the charger, cable, connector, CC path and dead-battery Rd configuration. ACE-ROM is not the first suspect because the controller has not yet received its VBUS-derived start-up power.
Stage 2 — VBUS powers the internal 3.3V LDO
The initial 5V powers the controller’s dead-battery supply. CD3217 creates PP3V3_UPC0_LDO at approximately 3.3V. This rail powers the controller boot domains and the external ACE-ROM device.
Diagnostic limit: PP3V3_UPC0_LDO proves that the first power conversion is working; it does not prove that the SPI flash contains valid data or that the controller successfully entered application mode.
Stage 3 — Internal boot ROM and boot-strap evaluation
A power-on reset releases the controller’s internal boot code. It initializes internal registers and clocks, reads the boot-strap condition, configures the SPI interface and decides where to look for a valid patch/configuration.
This internal ROM is the true first executable code. The external ACE-ROM is better described as the Apple-specific patch and configuration store rather than the controller’s entire firmware brain.
Stage 4 — External ACE-ROM is read over SPI
On the working A2442 capture, SPI_UPC0_CLK appears at about 31.920ms and SPI_UPC0_CS_L becomes active at about 32ms. The controller reads the external ROM using CLK, CS_L, MOSI and MISO. WP_L and HOLD_L must be in valid inactive states, the ROM must have stable 3.3V power, and the contents must match the board and controller configuration.
Check the complete transaction rather than only looking for one clock pulse. Clock and chip-select with no meaningful MISO response point toward ROM power, the ROM IC, corrupted contents, WP/HOLD biasing or a broken SPI trace. No clock or chip-select despite a good LDO points further upstream toward reset, boot straps or the controller itself.
Stage 5 — The managed 5V path reaches PPDCIN_AON
After the controller reaches a valid configured state and passes its attach and protection checks, the managed VBUS-to-system path conducts. In this A2442 measurement, PPDCIN_AON reaches approximately 5V at about 400ms.
This is an important correction to the simplified sequence: the internal power path does not have to wait for the later 20V contract. The board first receives default 5V through the managed path, and that 5V is sufficient to start U5200 and the early system sequence.
Stage 6 — ISL9240 starts the board from 5V
U5200 detects the 5V input through P_IN and CHGR_AUX_DET, creates CHGR_VDDP and enters boost mode. PPBUS_AON reaches approximately 12.3V at about 800ms. P3V8AON_PWR_EN then allows U5700 to create PP3V8_AON at about 1000ms.
The MPMU, SPMU and SoC can therefore begin booting while the external charger is still supplying only 5V.
Stage 7 — Embedded SMC communicates with CD3217
Later in the board sequence, the embedded SMC communicates with the port controller over I2C_SMC_UPC_SDA. The working A2442 capture shows this activity at about 4230ms. The controller is now operating with the Apple patch/configuration and the system is far enough through its own boot sequence to manage the requested power contract.
The active CC wire carries the USB-PD BMC messages: Source Capabilities, Request, Accept and PS_RDY. This is the “smart CC1/CC2 talking” that should be considered firmware- and policy-dependent.
Stage 8 — The port negotiates 20V and U5200 changes to buck mode
At approximately 4400ms, PPDCIN_AON rises from 5V to about 20V. The managed port power path remains active with its protection functions while U5200 receives the higher adapter voltage. At about 5200ms, PPBUS_AON settles near 12.0V as ISL9240 changes from boost to buck operation.
Therefore, 5V power-path enable and 20V PD negotiation are separate checkpoints. A board can have PPDCIN_AON at 5V but fail to reach 20V because of later SMC/I2C, CC, ROM-policy, charger-capability or controller faults.
Measured A2442/820-02098 CD3217 timeline
| Approximate time | Checkpoint | What it confirms |
|---|---|---|
| Before 0ms | Hardware Rd on CC1/CC2 | Dead-battery sink attach can be detected without loaded ACE-ROM. |
| 0ms | PPVBUS_USBC0 ≈ 5V | The charger detected Rd and enabled default VBUS. |
| 0ms | PP3V3_UPC0_LDO ≈ 3.3V | CD3217 dead-battery LDO and ROM supply are present. |
| 31.920ms | SPI_UPC0_CLK | The controller has started the external-ROM transaction. |
| 32ms | SPI_UPC0_CS_L activity | The external ACE-ROM is being selected. |
| ≈400ms | PPDCIN_AON ≈ 5V | The managed default-5V system power path is conducting. |
| ≈800ms | PPBUS_AON ≈ 12.3V | ISL9240 is operating in boost mode from the 5V input. |
| ≈1000ms | PP3V8_AON ≈ 3.8V | The PMU start-up supply is present. |
| ≈4230ms | I2C_SMC_UPC_SDA activity | The embedded SMC is communicating with CD3217. |
| ≈4400ms | PPDCIN_AON ≈ 20V | The high-voltage USB-PD contract has completed. |
| ≈5200ms | PPBUS_AON ≈ 12.0V | ISL9240 has changed from boost to buck mode. |
What different fault patterns really mean
| Observation | What is proven | Where to investigate next |
|---|---|---|
| No 5V VBUS at the connector | The dead-battery attach did not complete. | Charger, cable, connector, CC1/CC2 path and hardware Rd. |
| 5V VBUS but no PP3V3_UPC_LDO | VBUS reached the port, but the controller start-up supply failed. | LDO rail short, controller damage, local capacitors and VBUS supply pins. |
| 3.3V LDO present but no SPI CLK/CS_L | Only the LDO stage is proven. | Controller POR, boot straps, reset, clocking and the controller itself. |
| SPI CLK/CS_L present but MISO is absent or invalid | The controller attempted a ROM read. | ROM supply, ROM IC, contents, WP_L/HOLD_L and SPI traces. |
| ROM transaction looks valid but PPDCIN_AON remains 0V | Boot activity occurred, but the managed path was not enabled. | CC state, valid configuration, protection/sense conditions and the internal power-path block. |
| PPDCIN_AON reaches 5V but never 20V | Early ROM and default-5V path probably worked. | SMC progress, I2C_SMC_UPC, PD packets on the active CC line, charger capability and later policy. |
| PD packets and 20V appear at connector but not after the controller | The contract completed on the charger side. | Internal FET, voltage/current sensing, protection state and system-side loading. |
PP3V3_UPC_LDO present does not mean the ROM loaded
If VBUS is 5V, PP3V3_UPC_LDO is 3.3V and PP_HV/PPDCIN_AON remains 0V, the controller has certainly reached the LDO stage—but not necessarily the external-ROM stage. You must observe SPI CLK, CS_L and meaningful data before concluding that the ROM was read.
If SPI activity is normal and the configuration contents are known good, reasonable CC levels and BMC traffic help separate a policy/communication problem from a physically damaged managed power path.How to confirm a genuine ACE-ROM-related fault
- Compare ROM supply, CLK, CS_L, MOSI and MISO with a known-good port or known-good board.
- Verify WP_L and HOLD_L are not preventing normal access.
- Check continuity between the controller and ROM, especially after liquid damage or previous rework.
- Read the flash and verify that it is neither blank nor obviously corrupted.
- Use only a known-good image that matches the exact board/controller configuration.
- After repair, confirm the complete result: valid SPI read, 5V PPDCIN_AON, SMC-to-UPC I2C activity, CC BMC traffic, 20V negotiation and stable PPBUS_AON.
Frequently asked questions
Is all CC1/CC2 activity after ACE-ROM loading?
No. Hardware Rd and basic Type-C attach occur first. Normal configured PD policy and the later 20V BMC negotiation follow valid boot/configuration.
Does initial 5V prove that CD3217 is healthy?
No. Initial 5V mainly proves that the source detected a sink attach. Continue through the LDO, SPI-ROM and managed power-path checkpoints.
Does PP3V3_UPC_LDO prove that the external ROM is good?
No. It proves the ROM has a possible power supply. Only a valid SPI transaction and successful downstream behaviour demonstrate useful ROM loading.
Are CD3217 and TPS65983B exactly the same chip?
That exact identity is not publicly confirmed. TPS65983B is a valuable architectural reference for diagnosis, but Apple-specific silicon, boot configuration and firmware behaviour must be respected.
Related power-sequence guides
Continue with the A2442 M1 Pro master power-on sequence, the earlier Intel Mac charger and PPBUS_G3H sequence, or the MacBook logic-board power-rail diagnostic guide.
For professional component-level diagnosis, see our MacBook logic-board repair service in Melbourne and Australia-wide mail-in options.
