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.

TMS320F280039C: deadband value for EPWM configuration in tidm_02012 ecompressor control example

Part Number: TMS320F280039C
Other Parts Discussed in Thread: SYSCONFIG

Inside tidm_02012 example we have three different values for EPWM deadband as follows

1- value is 10 for both delays, inside sys config which reflects inside EPWM_init function, so this is the value used during initialization

2- value is 245 for rising edge delay and 225 for falling edge delay inside function HAL_initPWMCounts which is also called during initialization after the first one, so the first configuration will be useless 

3- using hardcoded deadband value to calculate the minCMPValue inside function HAL_setTriggerPrams, which is 24 (0.2*120)

 

I need to understand why there are different values because according to my understanding, they are all the same parameter, and what is the hardcoded value (33) that is used to calculate the minCMPValue, in this line 

pPWMData->minCMPValue = deadband + noiseWindow + 33U; 

  • Right, a lot of the count value settings in the PWM configuration of SysConfig are just initial placeholders since the actual values we want need to be calculated based on SYSCLK frequency, board properties, etc...and we can't do those calculations in SysConfig the way we can in C code. That's what HAL_initPWMCounts() is for.

    I do agree that what's being passed into that call to HAL_setTriggerPrams seems like it should be based off of the macros rather than hardcoded like that though. I'll file a bug report to get this updated in a future release.

    Thanks,

    Whitney

  • Thank you for your response,

    So, in this case the value passed to HAL_setTriggerPrams, should be based on the following deadband MACROS defined in hal.h

    1- MTR1_PWM_DBFED_CNT

    2- MTR1_PWM_DBRED_CNT

    And in this case which value should be used, the rising? or the falling?

    Also, can you please give me a reference to the bug that you will report to follow up and know when it will be fixed.

  • We typically assume the same value for both delays. Do note that the minCMPValue value that gets calculated usually only comes into play when you're using overmodulation, so if you aren't using overmodulation in your project, this shouldn't really have an effect.

    The bug ID is MWSDK-330. We don't have a public interface for looking up MC SDK bugs at the moment, but of course you can always request an update through E2E.

    Whitney