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.

TMS320F28027F: Regarding issues related to current protection when using MotorWare

Part Number: TMS320F28027F
Other Parts Discussed in Thread: DRV8301, MOTORWARE, BOOSTXL-DRV8301

Tool/software:

Dear Expert:
Previously, when I was using MotorControl_SDK (with the chip being F280025), the overcurrent protection was implemented using the CMPSS module.
However, recently, when I was using the F28027F chip and the software as MotorWare, I found that in the Lab5b program source code of Drv8301, there was no code similar to current protection? Was MotorWare not using the comparison module of F28027F?
If it was used, please kindly let me know where in the source code it is, and I am looking forward to your reply.

  • Hello,

    I'm currently looking into this to verify I give an accurate answer. I thought I recalled there being current protection in motorware, but when I opened the 5b project, I was also not able to find any in the HAL file. I'm talking to a few colleagues who might be more familiar with that aspect to see what, if anything, we've both missed.

    Regards,
    Jason Osborn

  • I've verified with a colleague that the old motorware projects do not have cmpss/comp protection enabled. I'd recommend either using the MCSDK or adding it yourself, if you need to use motorware.

    Regards,
    Jason Osborn

  • Hello, Jason:
    Thank you for your answer!
    I am currently using the LAUNCHXL-28027F + BOOSTXL-DRV8301 solution. If there is a hardware overcurrent, is it detected through the FAULT pin of the 8301 (the fourth pin on the to LaunchPad XL J1)?

    Also, after introducing this error pin (FAULT from BOOSTXL-DRV8301) into the software, is there a special protection method?

  • Per the schematic of the BOOSTXL-DRV8301, the general nFAULT output of the DRV8301 is the 3rd pin from the top of J1, not the fourth pin. The fourth pin specifically reports overcurrents. I'd recommend adding both.

    What do you mean special protection method? If you mean to ask how to implement the protection, simply routing the fault pins to the PWM XBAR, enabling the TZ inputs, and configuring the TZ actions will do it for you.

    Regards,
    Jason Osborn

  • I noticed the following code in the HAL_setupGpio() function:

    // FAULTn
    GPIO_setMode(obj->gpioHandle,GPIO_Number_28,GPIO_28_Mode_TZ2_NOT);
    
    // OCTWn
    GPIO_setMode(obj->gpioHandle,GPIO_Number_29,GPIO_29_Mode_TZ3_NOT);


    In HAL_setupPwms, there is: // turns off the outputs of the EPWM peripherals which will put the power switches

    // into a high impedance state.
    PWM_setOneShotTrip(obj->pwmHandle[PWM_Number_1]);
    PWM_setOneShotTrip(obj->pwmHandle[PWM_Number_2]);
    PWM_setOneShotTrip(obj->pwmHandle[PWM_Number_3]);

    Then in HAL_setupFaults(), there is:

    for(cnt=0;cnt<3;cnt++)
    {
    PWM_enableTripZoneSrc(obj->pwmHandle[cnt],PWM_TripZoneSrc_CycleByCycle_TZ6_NOT);
    
    PWM_enableTripZoneSrc(obj->pwmHandle[cnt],PWM_TripZoneSrc_CycleByCycle_TZ3_NOT);
    
    PWM_enableTripZoneSrc(obj->pwmHandle[cnt],PWM_TripZoneSrc_CycleByCycle_TZ2_NOT);
    
    // What do we want the OST/CBC events to do?
    // TZA events can force EPWMxA
    // TZB events can force EPWMxB
    
    PWM_setTripZoneState_TZA(obj->pwmHandle[cnt],PWM_TripZoneState_EPWM_Low);
    PWM_setTripZoneState_TZB(obj->pwmHandle[cnt],PWM_TripZoneState_EPWM_Low);
    }


    Do these configurations imply that both GPIO28 and GPIO29 pins can trigger the TZ interrupt of the ePWM?

  • Yes, that is the intent.