UCD90120 Initialisation

fault logging happens ~2ms after a fault is detected. It writing process will take ~75ms. If power is lost before writing is completed, the log becomes invalid. Then on the next power-up, the device will take up to ~180ms to initialize in order to erase the invalid log (normally ~20ms). The time taken is related to the number of flash sections to be erased. To avoid this condition, you can properly sequence down the rails before removing the power of UCD90120A. Otherwise UCD will treat the power-down as faults and invoke fault logging.

If VDD slew rate is less than 0.25V/ms, the device may not be properly initialized and enter lock-up condition (not functional).

Regards,
Zhiyuan

Unfortunately, I cannot sequence down the rails fully before power is removed. Could this explain why I get different start-up delays? Sometimes it takes ~130ms to start the sequence, but other times it's ~200ms, with exactly the same power-on  and power off situations. This unpredictability is causing issues in the system depending on which delay I get. These measurements are on the same unit under identical conditions.

I measured the same situation using a previous version ("D") of my sequence, and it has an equivalent delay of around 1 second compared to version E above.

The differences between D and E are that E has a different scale factor on one VMON Rail, and GPI1 was deleted (it is no longer used) on E. I deleted the pin assignment and the associated Pin Selected States.

What could cause such a start-up difference between these two versions with just these differences? Using version E, I added GPI1 back (but with no function and no Pin Selected State assignment), the start-up delay goes from 130ms/ 200ms to 1 sec. I don't understand why this should be so. I'm not using the extra GPI for any purpose here so what is causing the additional delay?

I did a Device Compare within Fusion and the differences are as I would expect. There wasn't anything obvious which would contribute to such a long delay.

Stuart

The 200ms delay can be explained as above. 1s delay is impossible.

Is the GPI used in any configuration? For example, Pin-Selected States or rail dependency. Is the GPI connected to any external circuit?

Is there any condition that can delay rail enable? For example, any dependency condition in the first rail. Also, is any MON pin voltage delayed due to RC filter?

I use GPI2 (pin 32, active high) to initiate the sequence. This is controlled off board, with just a pull-down on my board. This is a Pin-selected-State, where all rails are off if this is De-Asserted (State 0), and all rails are enabled when this input is Asserted (State 1). No other States are enabled.

I don’t think I have any conditions which would cause a rail enable delay, and there should be VMON pin voltages delayed due to RC filter.

Can I delay the measurement of a rail after it’s be enabled? If so, where is that option on Fusion? Is that the same as the glitch time parameter?

Please configure other Pin-Selected States as follows and see if the problem can be solved:

For the 4 states in which GPI2 is asserted, configure all rails to ON.
For the 4 states in which GPI2 is deasserted, configure all rails to OFF.

I tried your suggestion but unfortunately, it does not make any difference.

Note that I actually use GPI0 (pin 32) as my enable. I said in an earlier post it was GPI2, but that was my mistake - the Pin Selected States tab on the GUI is a little confusing here since it refers to GPI2, GPI1, GPI0, where GPI0 is mapped to GPI2_PWM. In the Pin Assignment tab, it's not obvious that GPI0= GPI2_PWM.

Anyway, I set up and enabled all the States asserted/ de-asserted as you indicated, but it still starts up with one of two delays, with no obvious indication as to why.

Can you send the project file? I can look into it.

From which signal to which signal did you measure 1sec delay?

Can I send you the file directly rather than post here?

I measure my rails relative to the input GPI signal.