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.

LAUNCHXL-F280049C: MCSDK build level 3 OVC faults

Guru 55913 points
Part Number: LAUNCHXL-F280049C
Other Parts Discussed in Thread: DRV832X

Hello,

Why does build level 2 start & run motor 3.5A and easily force OVC trip fault 2.5A via CMPSS DACH/L. Then build level 3 OVC fault trip 6.5A during startup spins motor then cause OVC fault via CCMPS DAC-L/H, mostly H latch? Note both levels required ADC_FULL_SCALE_CURRENT setup as P2P ±2048 being 1.3A rated motor required to set OVC fault trip point 6.5A in open loop build level 2. Oddly stall current (2.9f) and the rotor spins then stalls as it passes 2.9A and OVC occurs in closed loop DMC level 3. ADC full scale current (4096 counts) via CMPSS DACH/L values were based on P2P current ±2048 based on the PWM action qualifiers for DACA1-H/L DACB1-H/L being H or L. My C code case DAC latches remain high impedance state until comparator +Input level exceeds the preset values below. However, the invert state of DACB1-L output does not remain high impedance, for unknown reason that condition could not be qualified in both MCSDK or SDK hal.c..

obj->dacCMPValH = 2048 + cmpValue;
obj->dacCMPValL = 2048 - cmpValue;

Notice: objSets->maxPeakCurrent_A = (USER_M1_ADC_FULL_SCALE_CURRENT_A * 0.495f); Perhaps ADC full scale current might check P2P as it seems more accurate measure via CMPSS DACSH/L.

Could USER_M1_FAULT_CHECK_CURRENT_A  (0.05f) be to low being well below stall trip fault level? Can to low setting be reason why OVC occur during closed loop motor run but not during open loop?

Oddly current trip testing build level 2 defaults to USER_M1_MAX_VS_MAG_PU  (0.576) without any current reconstruction being noticed in the code. So I reduced ~MAG_PU to 0.5 and it still OVC faults during closed loop startup and we have to manually clear moduleOverCurrent bit after clearing flag is forced set 1. Something in the clear fault bits code does not allow all bits to be cleared by motorVars_M1.flagClearFaults being set 1. However faults clearing worked great in SDK4.0 when we set motorVars_M1.faultMtrUse.all to 0 it cleared all fault flag bits.

In conclusion the motor attempts to run closed loop but trips OVC in the above examples of build level 3 and not in build level2. Seems illogical that we can cause a forced OVC trip at much lower (2.5A) build

level 2 and can't get motor running from the same ADC inputs at twice the OVC trip level (6.5A) in build level 3. What should we be looking at that is causing this mayhem?

DMC build level 2: I set the USER_M1_FAULT_CHECK_CURRENT_A threshold 1.35A but requires set motorSetVars_M1.overCurrent_A (2.25A) to get motor running without driving OVC trip, mostly DACA1-H latches of 3 CMPSS also build level 3 similar results. The OVC trip point in open loop is <0.8A so why does it trip OVC in build level 3 when starting up?

#define USER_MOTOR1_FORCE_DELTA_A (0.05f) // A
#define USER_MOTOR1_ALIGN_DELTA_A (0.01f) // A
#define USER_MOTOR1_FLUX_CURRENT_A (0.325f) // A
#define USER_MOTOR1_ALIGN_CURRENT_A (0.325f) // A
#define USER_MOTOR1_STARTUP_CURRENT_A (0.325f) // A
#define USER_MOTOR1_TORQUE_CURRENT_A (0.65f) // A
#define USER_MOTOR1_OVER_CURRENT_A (2.25f) // A

  • What should we be looking at that is causing this mayhem?

    Differences between the ADCIN channels 2x to 4x Lauch pads tends to escape TRM and visual inspections. There was found SDK4.0 and UMCSDK was not indicated via x49 TRM or Pin Map card relative to the current macro names of MCSDK. The motor would run and force trip fault DMC build level 2 but not in level 3. Had the MDACS been made functional the phase relationship of the inputs may have been more evident. Oddly two AIN ports A8 and B8 are not the same inputs 2x to 4x.

    There are many #if #endif to enable MDACS adding even more unknows and likely compile errors and did not have the 4 channel DAC board to test with.

  • Hi GI,

    Perhaps ADC full scale current might check P2P as it seems more accurate measure via CMPSS DACSH/L.

    The ADC_FULL_SCALE_CURRENT need to be modified according to customized system. It is the actual equivalent analog current corresponding to ADC full range (4096).

    Notice: objSets->maxPeakCurrent_A = (USER_M1_ADC_FULL_SCALE_CURRENT_A * 0.495f); Perhaps ADC full scale current might check P2P as it seems more accurate measure via CMPSS DACSH/L.

    Referring to function "calcMotorOverCurrentThreshold()" in motor_common.c, the "objSets->maxPeakCurrent_A" limits the value "objSets->overCurrent_A" that set by users.

    Could USER_M1_FAULT_CHECK_CURRENT_A  (0.05f) be to low being well below stall trip fault level? Can to low setting be reason why OVC occur during closed loop motor run but not during open loop?

    The "USER_M1_FAULT_CHECK_CURRENT_A" is only applied in "runMotorMonitor()" and it seems it is not used in overcurrent protection logic.

    In conclusion the motor attempts to run closed loop but trips OVC in the above examples of build level 3 and not in build level2. Seems illogical that we can cause a forced OVC trip at much lower (2.5A) build

    level 2 and can't get motor running from the same ADC inputs at twice the OVC trip level (6.5A) in build level 3. What should we be looking at that is causing this mayhem?

    In build level 3, the motor is running via i/f control. In this level, the current loop is closed and id is regulated to follow id_ref, iq is regulated to follow iq_ref through their own PI controller. Given that the current protection is proved to work properly in build level 2, if the OVC is triggered in this build level, the reason would be the transient current exceeds the overcurrent threshold. Could you capture and check the actual current waveform during start-up in this build level?

    Thanks,

    Jiaxin

  • Hi GI,

    Not sure if I grasp your meaning properly, but migrating the motor control reference code from F28002x to F28004x does need some re-configurations. Developers can refer to Page 70, Section 3.3 of the user guide for detailed explanations.

    Thanks,

    Jiaxin

  • Hello Jiaxin,

    Developers can refer to Page 70, Section 3.3 of the user guide for detailed explanations

    It does not cover x49c using 3 CCMPS and 6 independent MUX channels, though TRM table 9-2 elaborates such potential. Perhaps driverlib Hex decodes used set MUX ports for DACLB1 are crossed with something Specifically, XBAR table 9-2 MUX 2,7,11 into EPWM combination 5,7,9. All 3 DACLVALL-B1 inverted outputs are not constrained by 2048 - 0x0000 counts set for the OVC trip level.

    The issue is CMPSS DACL-B1-L when enabled all 3 phases cause instant unlatched OSHT fault when we set run identify and enable 1. So the Xbar combination has to be disabled and the action qualifiers shown below. Can you look into why this is occurring or an errata exists?

    Oddly only B1 low action qualifier OST events are affected. We should not have to disable the action qualifier to stop OVC fantom tripping. So DCA1 low action qualifiers work as expected but not the B1 invert state shown below. Note the CMPSS have filtered asynchronous outputs and hysteresis level 1 or 2 does not help. after some thought I personally lean towards EPWM action qualifier being culprit as Fig.3-4 shows DACL B1-L is enabled.

    //EPWM_selectDigitalCompareTripInput (obj->pwmHandle[cnt], EPWM_DC_TRIP_COMBINATION, EPWM_DC_TYPE_DCBL);

    // Trigger event when DCB1 is Low
    //EPWM_setTripZoneDigitalCompareEventCondition(obj->pwmHandle[cnt],
    //EPWM_TZ_DC_OUTPUT_B1,
    //EPWM_TZ_EVENT_DCXL_LOW);

    Can you explain the logic behind Fig.3-4 has only 2 CMPSS DACS, e.g. OVC detection High phase U, H/L phase V and Low phase W? Since the MUX ports enabled via the MCSDK code do not enable DACL-B1-H events. What if there is a negative OVC condition on U phase? Applicaiton has to wait 50us for PWM to cycle (20KHz) for OST fault trip? I get the DRV832x/3x/5x has nFault Tz detection though not all systems will use low voltage gate drivers. The MCSDK code configures 2 CMPSS Mux channels for BSXL8323RS. The code shown below is a similar model having issues with x49c DACL-B1-L state (above) but with 3x CMPSS.

    #define MTR1_IU_XBAR_OUT_MUX XBAR_OUT_MUX00_CMPSS1_CTRIPOUTH            // CMPSS1-HP
    #define MTR1_IV_XBAR_OUT_MUX XBAR_OUT_MUX04_CMPSS3_CTRIPOUTH_OR_L // CMPSS3-HP&LP
    #define MTR1_IW_XBAR_OUT_MUX XBAR_OUT_MUX01_CMPSS1_CTRIPOUTL            // CMPSS1-LP

    ASysCtl_selectCMPHPMux(MTR1_IU_CMPHP_SEL, MTR1_IU_CMPHP_MUX);
    ASysCtl_selectCMPLPMux(MTR1_IU_CMPLP_SEL, MTR1_IU_CMPLP_MUX);

    ASysCtl_selectCMPHPMux(MTR1_IV_CMPHP_SEL, MTR1_IV_CMPHP_MUX);
    ASysCtl_selectCMPLPMux(MTR1_IV_CMPLP_SEL, MTR1_IV_CMPLP_MUX);

    ASysCtl_selectCMPHPMux(MTR1_IW_CMPHP_SEL, MTR1_IW_CMPHP_MUX);
    ASysCtl_selectCMPLPMux(MTR1_IW_CMPLP_SEL, MTR1_IW_CMPLP_MUX);

    Not sure if I grasp your meaning properly

    BTW: The MCSDK is so much better to determine Ls_d/q_H inductance and only 100mΩ high Rs impedance via detached custom inverter. I am pickeled tink over motor ID and ESMO seems to quiet vibration especially >10KRPM >350Hz Nerd

  • Given that the current protection is proved to work properly in build level 2, if the OVC is triggered in this build level, the reason would be the transient current exceeds the overcurrent threshold. Could you capture and check the actual current waveform during start-up in this build level?

    I just now see this post, was not there the other day and only your 2nd response was showing. 

    Not sure if I grasp your meaning properly

    The problem with tripping OVC faults build level 3 was due to two AIN inputs begin crossed as I mentioned above post. Hence there is odd difference between x2 and x4 AIN4 inputs ADC-A/B  (W/V- IA) were crossed.

    However that does not answer why OVC threshold is seemingly 50% higher in the full scale ADC peak 4096, rather than more accurately peak to peak or 2048 counts for the CMPSS DACS ±2048 threshold. Test it for yourself the OVC trip point level 2 and 3 then divide ADCFs current defined. Testing current amps INA240A1 20V/V 2mΩ shunts on DC inverter, suggests 82A peak but OVC trips are more accurate 41A P2P with very low currents.

  • Hi GI,

    In terms of customized hardware, the configuration for each peripheral should be modified. Page 70, Section 3.3 of the universal motor control lab user guide gives a system-level instruction on how to run the code with a different C2000 device. Please refer to the TRM if there are any doubts on how to configure a specific peripheral.

    Please also make sure the actual current measurement matches the digital value that you observed from the CCS debugger.

    Thanks,

    Jiaxin

  • Please refer to the TRM if there are any doubts on how to configure a specific peripheral.

    Again have configured it to use 3 CMPSS as would be more prudent than just using two. Hence each CMPSS is independent as in SD4.01. The reason Fig.3-4 shows two CMPSS seemingly due to 2x/3x MCU class do not have 3 CMPSS or 3 ADC modules.

    So it now has three ADCS and 3x PPB's sampling the 3 phases both H/L OVC conditions on any phase since there is no DRV832x gate driver.