In the Fusion GUI software, under Device, Export, tab "PMBus", I can export a script of write (and other) commands to write the configuration.
I wrote a parser to process that script.
In the exported csv script, the first 3 writes disable all rails.
Also I noticed that, even if I comment them out, the command F6h SEQ_CONFIG also has the effect that the selected rail shuts down.
I have a very small MCU in my system which can directly talk to the UCD via I2C, and which is not depentant on any rail controlled by the UCD.
The MCU cannot buffer all the bytes that need to be written for a complete configuration of the UCD.
A bigger CPU has no access to the I2C bus of the UCD, but can talk to the MCU.
I was thinking of buffering parts of what needs to be written - namely only those commands which really require the rails to be off (or force the rails to be off, llike SEQ_CONFIG apparently does).
So I could configure most of the UCD from the running CPU (tunneling via MCU), and then, at the end, I buffer those "delicate" commands in the MCU, and when it writes them, the CPU system reboots because it shuts down the rails and reactivates them, but all is good in the end.
Would that work that way?
Which of the parts of the config sequence work without rails being / needing to be disabled?
Edit: I found the mention of the rails being deasserted by the F6h command in the reference in a note, and have not seen this anywhere else.
I am still wondering whether the order of how things are done in the PMBus write script exported by Fusion is important in some parts, or I can reorder things at will, such that I will put the rail-deactivating commands at the very end of things, instead of relatively close to the beginning of the file. And I haven't seen anything yet about whether this shutting off of all rails at the very beginning of the exported script is necessary for any of the commands.