This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TPS65224-Q1: TPS6522432WRAHRQ1

Part Number: TPS65224-Q1

Tool/software:

Hello Team

    We are using Voltage Monitor function of TPS65224-Q1, to detect the under voltage and over voltage conditions on the output voltages of the BUCK and LDO regulators.

    How can we valid this function on our system? Is there any way for injecting fault, then the MCU can read error status from register STAT_LDO_VMON .

Best Regards.

Xianti

  • Hi Xianti,

    There aren't any sort of software error injection methods on the device if that is what you are looking for. Only way to cause LDO or BUCK fault is to actually cause the fault by physically injecting over or under voltage to the output. Large output load transient with tight monitoring window could also trigger the fault.

    Note that STAT_LDO_VMON is the real time status register. You can get the latched fault from INT_LDO_VMON register.

    BR,

    Samuli

  • Hi Samuli

        Thanks for your reply.

        Regarding the latch fault of INT_LDO_VMON, is there any debounce processing? For example, if the under voltage occurs for 5ms, the latch bit will be set.

    Best Regards.

    Xianti

  • Hi Samuli

        We are trying to inject fault at Buck3, using another power supply to provide an external voltage at this position as below figure.

        We set these registers of PMIC:

                    BUCK3_VMON_EN bit as 0x1 at BUCK3_CTRL Register,

                    BUCK3_VMON_THR bit as 0x0 (±3%) at BUCK3_PG_WINDOW Register

        After power up, we injected 1.9V at  output of Buck3.

        We cyclically read the STAT_BUCK register, but it is always 0x00.

        Is this method correct? as you mentioned  physically injecting  to the output.        

    Best Regards.

    Xianti

  • Hi Xianti,

    Buck OV or UV will cause a MCU_POWER_ERROR and the reaction is to shutdown the regulators as well as their voltage monitors. You should be able to verify this by reading the BUCK3_VMON_EN bit back and it should be 0. This is why you will very likely not able to catch/read the real time status register for the fault. However, you should be able to see BUCK3_UVOV_INT being set to 1. Could you try polling that register instead of the status register?

    Debounce/deglitch time for UVOV detection is set with VMON_DEGLITCH_SEL bits. By default it should be 4 µs.

    BR,

    Samuli

  • Hi Samuli

         We read the INT_BUCK register, but the value always is 0x0 when we inject a over voltage.

        We initial MASK_BUCK register as 0x0 .

    BR.

    Xianti

  • Hi Xianti,

    Are you able to actually observe that the output voltage is actually dropped or increased by the power supply? The buck will try to regulate back to the original level and if you do not have a strong enough forcing the buck will either sink or source the forced voltage "away". Increasing the current limit in the power supply used for forcing should help.

    BR,

    Samuli

  • Hi Samuli

        We used a multimeter to measure the output of Buck, and its voltage is actually over the threshold.

        We observed the current of injected power is about 0.3A.

    Best Regards.

    Xianti

  • Hi Xianti,

    The voltage at the feedback point is very likely not above the threshold and the buck can easily sink that extra voltage. Instead of doing an overvoltage test I would recommend trying to do under voltage. It is likely a safer test for the processor side as you can keep lowering the injection voltage until you get the OVUV interrupt.

    BR,

    Samuli

  • Hi Samuli

        We tried to inject an under voltage, but PMIC would pull up the voltage.

        For example, we injected 1.7V at the output of Buck3 which output is set as 1.8v, but the voltage at the output would be pull up as 1.8V by PMIC.

    BR.

    Xianti

  • Hi Xianti,

    The that supply used for the injection may not be able to sink current. You need a strong enough injection for the OV/UV so that PMIC cannot regulate the output voltage to the correct level. The voltage the PMIC sees is at the feedback point. If you have a way to directly inject the voltage to the feedback pins that would be the best way to proceed.

    A colleague of mine wrote a nice guide in another E2E thread for a different device.

    You can force the voltage as you said but you will need a power supply that can source a lot of current. Also it is best if both of the supplies (input and the one forcing output) would be Keithley supplies or something else that can also sink current. This is because in both OV and UV the other one has to sink current. In OV test the input side is sinking and in UV test the output supply is sinking. Keep in mind that with this device the thresholds for OV/UV are +/- 90mV so you don't have to try to force as much as you already tried. 

    If one power supply can supply more current than the other connect that to the side which be supplying the current. (In OV test the output side supply is supplying the current and in UV the input side is supplying the current)

    How to perform (OV):

    1. Connect supplies to input and output (make sure input side supply can sink current). Connect multimeter to buck/boost feedback (This is the voltage you are monitoring since the device sees this voltage and monitors it)

    2. Dial the input voltage as should and output to 1.8V

    3. Dial the current levels to 2A at first. Raise if needed 

    4. Turn on the input supply

    5. Turn on the output supply

    6. Slowly start increasing the voltage at the output side and monitor the current consumption and multimeter level. If the power supply current limit is reached increase the limit (step 3).

    7. Increase until you hit the OV interrupt

    Do this same for UV but make sure now the output side supply can sink the current.

    Be aware that this kind of forcing can break the device if not careful!

    BR,

    Samuli