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.

TMS320F28388D: HRPWM operation and the MEP with zero steps

Part Number: TMS320F28388D

Hi,

Sorry it took so long for the follow-up on the previous topic.

At the end of our last conversation I still had a few unanswered questions, which as of today are not yet answered by the Technical Reference Manual.

My question :

I'm confused, does it mean that the HRPWM extension will not work properly if I don't perform a "dummy" write in my initialization code?

Answer :

It does work, but the set of accepted values are from 0x1 and up. Using the value 0 for the HR section will not give you the correct ePWM frequency that you assume. That is becuase the 0x0 value in the HR portion does not mean your PWM calculation is the same as if you had your HRMODE disabled.

My new question :

Sorry I don't get it. Every single document about the HRPWM I've come accross basically says that CMPAHR value = (number of MEP steps) << 8. So what you are saying is that this is true except in the case where I want zero MEP steps?

For example the formulas in chapter 26.15.1.5.2 Scaling Considerations explicitely show how the value of CMPAHR should be based on frac(PWMDuty*PWMPeriod). Do you mean that this formula is actually wrong if PWMDuty*PWMPeriod happens to be an integer without a fractional part?

Another excerpt from the latest TRM :

26.15.1.5.2 Scaling Considerations

In a practical application, however, it is necessary to seamlessly provide the CPU a mapping function from a per-unit (fractional) duty cycle to a final integer (non-fractional) representation that is written to the [CMPA:CMPAHR] register combination.

The sample assembly code from the latest TRM :

Example 26-4. HRPWM Buck Converter Run-Time Code

MOVW DP, #_HRBUCK_In
MOVL XAR2,@_HRBUCK_In ; Pointer to Input Q15 Duty (XAR2)
MOVL XAR3,#CMPAHR1 ; Pointer to HRPWM CMPA reg (XAR3)

; Output for EPWM1A (HRPWM)
MOV T,*XAR2 ; T <= Duty
MPYU ACC,T,@_hrbuck_period ; Q15 to Q0 scaling based on Period
MOV T,@_MEP_ScaleFactor ; MEP scale factor (from optimizer s/w)
MPYU P,T,@AL ; P <= T * AL, Optimizer scaling
MOVH @AL,P ; AL <= P, move result back to ACC
ADD ACC, #0x080 ; MEP range and rounding adjustment
MOVL *XAR3,ACC ; CMPA:CMPAHR(31:8) <= ACC

In this sample code there is no check of any kind about the MEP step count. And this code has been in your docs forever. I have spotted it in the HRPWM user guide for the F2803x from ten years ago.

This worries me. Is the procedure performed by the sample code above not correct? If not why are the docs not up to date?

Kind regards,

Pierre

  • Pierre,

    Always do an or with 0x0100 for CMPAHR.

    So the value is never ZERO.

    I have tested this on HW, dont use the value ZERO please.

    Always,

    CMPAHR = 0x0100 | desired_value

    Nima

  • Nima,

    Why no ZERO value? What do you mean you tested this on HW? What about the thousands of units which have been shipped over the past decade with software that sets ZERO values to CMPAHR as per the official docs ?

    I need to know more about this issue. Is it only the F28388D? Is it only ePWM Type 4? Or is it an issue with every HRPWM module ever?

    Also if I'm not mistaken performing this logical OR would add 1 step to any even step count, thus effectively dividing the resolution of the HRPWM by 2? Is this correct?

    Regards,

    Pierre

  • I have the 0x0100 ored when the value for desired_value is zero.

    This is a type4 EPWM setting. I'm not sure about Type2.

    I will let and respond for Type2.

    Nima

  • Pierre,

    To the best of my knowledge there has been no change in the behavior of the older Type 2 PWM and the Type 4 PWM. 

    It's been a while since I've thought about this exact boundary condition, but I believe that enabling HRPWM with a value of zero will simply apply a small shift to the PWM's edge which will cause the output to be slightly different than expected. As long as the CMPAHR value is 1 or greater this shift will not be seen. , please confirm the exact behavior there should be no difference for Type 2 and Type 4.

    Regards,
    Cody 

  • Hi,

    Can we expect the technical documents to mention this shift at some point? A definitive (and consistent across forums/docs/libraries) explanation of this delicate matter is overdue. Even on the E2E forums I see topics where the suggested solutions on how to use CMPAHR seem to ignore the existence of this behaviour (such as this one from barely a week ago).

    Kind Regards,

    Pierre

  • Yes we will add this to the next revision of the TRMs.

    We are still accessing this internally once this is closed I will send you a message.