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.

CCS/UCD3138A: Question of ACOMP

Part Number: UCD3138A

Tool/software: Code Composer Studio

For over current protection respond quickly, use the anlog compartor. when the output voltage under a value or the output current above a value, it is define that the over current protection occur. The output voltage use the anlog compartor of C and the output current use the anlog compartor of D. And the initinal code is as follow:

FaultMuxRegs.ACOMPCTRL1.bit.ACOMP_D_THRESH = OCP_CMP_REF;

FaultMuxRegs.ACOMPCTRL1.bit.ACOMP_D_SEL = 0; 
FaultMuxRegs.ACOMPCTRL1.bit.ACOMP_D_POL = 1;  

FaultMuxRegs.ACOMPCTRL1.bit.ACOMP_C_THRESH = UVP_CMP_REF;

FaultMuxRegs.ACOMPCTRL1.bit.ACOMP_C_SEL = 0;   
FaultMuxRegs.ACOMPCTRL1.bit.ACOMP_C_POL = 0;   

If the fault happen, it will be done in the fast interrupt. It will see the flag of CimRegs.FIQIVEC.all and FaultMuxRegs.FAULTMUXINTSTAT.all.

1. I could not find the list of CimRegs.FIQIVEC.all. where can i get it?

2. when the over current occur twice times and recover it, the module could not start up. I see some information through PMBUS. The register of FaultMuxRegs.ACOMPCTRL1.bit.ACOMP_C_INT_EN,Dpwm2Regs.DPWMINT.bit.PRD_INT_EN,Dpwm0Regs.DPWMCTRL1.bit.GPIO_A_EN are all right.

If disable the anlog compartor of C(Vout UVP), the module can start up after the over current occur lots of times. why? And I use debug i/o for see the fault if always happen. But the debug i/o only change sometime. And the wave is as follow:(ch2:debug i/o ch3: current) If the debug i/o change happen, it express that the flaut have been detected.

  • For your first question, the interrupt numbers are in the datasheet for each device, rather than in the technical reference manual. They change from device to device as features are added or deleted. In the current UCD3138A data sheet, they are in section 7.4.4 , Central Interrupt Module. Here is the datasheet: www.ti.com/.../ucd3138a.pdf

    For your other question, once the fault occurs, you need to take action to restart the DPWMs. On any device, you can enable and disable the DPWM, either with the GLBEN bits or in the PWM_EN bit in each DPWM. On the A devices, the FLT_RESTART bit is added to the DPWMFLTCTRL register. Setting this bit will restart DPWM B after a fault without stopping DPWM A. It can also be used to restart DPWM A without stopping DPWM B. Note that FLT_RESTART does not reset itself. When using it, it is necessary to return it to zero after each use so that there will be a rising edge to trigger the next restart.
  • Thank you for your reponse.

    About question 2, i could not describe claerly. After the fault occur,  i will set the register of LoopMuxRegs.GLBEN.all to 0 and set the ocp flag,disable the anlong compator. Then use the statemachine to do the fault. In the statemachine, i will disable the DPWMA and DPWMB, initilize the pwm function again. After the ocp flag clear, the module will restart the start up process.

    The process can restart twice times. In the twice times, the module restart sucessfully. But at the third time, it is unsucessfully. If disable the anlog compator of C(Vout UVP), the module can always restart sucessfully. I don't know the reason. I get some debug information through PMBUS and see the register of LoopMuxRegs.GLBEN.all, Dpwm0Regs.DPWMCTRL1.bit.GPIO_B_EN,Dpwm1Regs.DPWMCTRL1.bit.GPIO_B_EN,Dpwm0Regs.DPWMCTRL1.bit.GPIO_A_EN,
     Dpwm1Regs.DPWMCTRL1.bit.GPIO_A_ENFaultMuxRegs.ACOMPCTRL1.bit.ACOMP_D_INT_EN,FaultMuxRegs.ACOMPCTRL1.bit.ACOMP_C_INT_EN,FaultMuxRegs.ACOMPCTRL1.bit.ACOMP_C_THRESH,

    FaultMuxRegs.ACOMPCTRL1.bit.ACOMP_D_THRESH. They are right.

    when the module restart unsucessfully, the FaultMuxRegs.FAULTMUXINTSTAT.all is 0x08. But i have read and clear the interrupt flag through give the value to temp. Is it the reason?

    I use debug i/o to see if the fault happen. you can see the picture. Why the debug i/o is not change every time?

    So i need your suggestion. Thanks!

  • There are so many bits and complications that I can't really debug it from here. You just have to look through all the bits while it is running and see what is wrong. It's kind of like tracing analog circuitry to see where the signal is going wrong. If the FAULTMUXINTSTAT stays at an 8, that means that the ACOMP-C keeps getting triggered - that the signal keeps going above and below the threshold. It's edge sensitive, so if it stays high or low, you will get at most 1 interrupt. The bit is cleared by a read, so if you keep reading, you will see 1 only if it's triggered again.
  • Ok. Thanks ! I will see it and debug it.
    But the other question is as follow:
    I use debug i/o to see if the fault happen. you can see the picture. Why the debug i/o is not change every time?
  • Again, the answer is the same - something along the chain to that point is broken.
  • I disable the CMP_D(OCP) and enable CMP_C(VOUT_UVP). The module will be latch off after ACOMP_C interrupt occur one time. Then I see the register of FaultMuxRegs.FAULTMUXINTSTAT.all(0),FaultMuxRegs.DPWMXFLTABDET.bit.ACOMP_C_EN(1), FaultMuxRegs.ACOMPCTRL1.bit.ACOMP_C_INT_EN(1). They are right. Also i read the register of FaultMuxRegs.ACOMPCTRL1.bit.ACOMP_C_THRESH(40). The value is 40. The ADC of vout is 0x0b. The value of adc is below ACOMP_C_THRESH. But the interrupt is not occur. Why? which register need i see?

  • I disable the CMP_D(OCP) and enable CMP_C(VOUT_UVP). The module will be latch off after ACOMP_C interrupt occur one time. Then I see the register of FaultMuxRegs.FAULTMUXINTSTAT.all(0),FaultMuxRegs.DPWMXFLTABDET.bit.ACOMP_C_EN(1), FaultMuxRegs.ACOMPCTRL1.bit.ACOMP_C_INT_EN(1). They are right. Also i read the register of FaultMuxRegs.ACOMPCTRL1.bit.ACOMP_C_THRESH(40). The value is 40. The ADC of vout is 0x0b. The value of adc is below ACOMP_C_THRESH. But the interrupt is not occur. Why? which register need i see?
  • It's hard to say. You need to make sure you're not reading the faultmuxintstat register with your code somewhere else and clearing it. As I think I've mentioned, if the timing is perfect, sometimes we see the DPWM shut off without an interrupt from the fault, but that's normally from the pulse being very short, which doesn't seem to be the case here. We do recommend using the DPWM fault registers instead to avoid all these issues.