Electronics Design AUSTUSB4500 negotiates my custom PD profile fine over I2C, but reverts to 5V after every power cycle
Asked by stale_biscuit_03 ·
Bringing up a custom board with an STUSB4500 as the PD sink controller — no MCU involved in the negotiation, it's meant to be fully autonomous. I want it to request 12V/2A instead of the 5V default, so I've been using ST's GUI (STSW-STUSB4500) over I2C to write the 3 PDO sink capability registers with my custom voltage/current values, then triggering a renegotiation.
It works. The board pulls 12V, my downstream buck converter sees the right input, LED confirms PD contract at 12V. Great.
Then I unplug the USB-C cable to move the board to the bench supply for a current measurement, plug it back into the same PD source ten minutes later — and it's back to requesting 5V. Like none of my I2C writes ever happened. I re-run the exact same GUI sequence and it works again, until the next power cycle.
Am I writing to the wrong registers? I assumed writing the PDO sink capability registers over I2C was persistent since the chip is supposed to run standalone without a host MCU re-configuring it on every boot.
3 Replies
That symptom is the classic sign you're writing to the STUSB4500's working registers, not its NVM. The two are easy to conflate because they're both reached over the same I2C bus and the chip behaves identically either way right up until the next power-on reset — that's what makes this so confusing to bring up cold.
The two register spaces
The STUSB4500 has a runtime (working) register set that applies immediately — write a new PDO there and the chip renegotiates on the spot, exactly like you observed. But those registers are RAM-backed and reset to whatever's baked into NVM the moment VBUS (or VDD) is removed and reapplied. If your GUI session is only touching the working registers, everything looks correct until the power cycle wipes it.
NVM is a separate, non-volatile memory bank inside the part that's read out and copied into the working registers automatically on every power-on. That NVM is what makes the chip "autonomous" in the first place — no MCU has to babysit it at boot. To make your 12V/2A profile survive a power cycle, you have to actually program the NVM sectors, not just the live registers.
How NVM programming differs from a working-register write
Per ST's I2C configuration application note (AN4879) and the STSW-STUSB4500 GUI documentation, writing NVM requires a specific unlock → erase → program → verify → lock sequence — it isn't a plain register write. Roughly:
- Write the NVM access password to the password register to unlock write access.
- Put the chip in NVM programming mode (a control register write) rather than normal operating mode.
- Erase the target sector(s) — NVM sectors typically have to be erased before they can be reprogrammed, same as flash.
- Write your PDO values into the sector.
- Issue the program command and poll/verify the write completed.
- Exit programming mode and re-lock.
If your I2C sequence only does step "write PDO register" without steps 1–6 wrapped around it, you're doing a working-register write every time — which is exactly the "works until the next power cycle" behaviour you're seeing.
Fastest way to confirm this diagnosis
Use the official STSW-STUSB4500 GUI's "Write to NVM" action specifically (not just "Apply" or "Send"), if you haven't already — the GUI exposes both a live-apply button and a separate NVM-commit button, and it's very easy to click the wrong one during bring-up since both make the board look correct immediately. If you're doing this from your own I2C driver rather than the GUI, cross-check your sequence byte-for-byte against ST's reference NVM programming sequence in AN4879 rather than reconstructing it from the register map alone — the unlock/erase/program ordering matters and getting one step out of order can silently no-op the write while still returning I2C ACKs.
To add the "why does this even ACK successfully if it's not working" part: the working registers and the NVM sector registers sit at different addresses/pages, so a write to the wrong one doesn't fail — it just writes somewhere that gets thrown away on the next POR. I2C has no concept of "this write didn't stick long-term," it only ACKs "I received these bytes." That's why this bites people who are otherwise checking their return codes correctly.
One more gotcha on top of what i2c_inspector described: after you successfully commit to NVM, power-cycle the board and immediately re-read the working registers (not the NVM registers) to confirm the values you expect actually got copied out of NVM on boot. If NVM programmed correctly but you still see 5V after a fresh power-on, the fault has moved to your renegotiation trigger logic rather than the NVM write itself — worth separating those two failure modes before you assume the NVM commit didn't take.
Worth saying explicitly: this whole class of bug is the trade-off you accept by choosing an autonomous PD sink like the STUSB4500 over a firmware-driven controller like the FUSB302. Autonomous NVM parts are genuinely nice when there's no MCU on the board at all, but if you do have a host MCU anyway, having it push the PDO configuration to a FUSB302 (or similar) fresh on every boot sidesteps NVM programming entirely — there's no "did the write persist" question because you're not relying on persistence, you're reconfiguring from known-good firmware state every power-up.
Not saying switch parts mid-bring-up over this — the NVM sequence in AN4879 works fine once you've got it right once, and you won't have to touch it again after that. But if you're evaluating PD controllers for a future board revision and you already have an MCU sitting there for other reasons, it's worth weighing whether you want NVM programming as a one-time production step (STUSB4500) versus configuration-in-firmware on every boot (FUSB302). Depends whether your production line is set up to run an NVM programming step at all — some contract manufacturers won't want to add a custom I2C programming fixture to the test jig.