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-F28379D: Incorrect HR phase offset value for ePWM configured in up-down count mode

Part Number: LAUNCHXL-F28379D

Hi,

I am facing issue setting the phase offset value for decimal values in HRPWM in up-down  count mode. I have updated the example epwm_up_aq_cpu01 to perform the following settings.

1) Generate ePWM1 syncout to ePWM2

2) update phase value to TBPHS and TBPHSHR register for every sync event.

3) Use auto conversion to update mep_scale factor.

4) Use count up as the direction after phase update.

Code shown below.

for(;;)
{
EPwm2Regs.TBPHS.bit.TBPHS = (Uint16)phaseVal;

/*-- Update TBPHSHR --*/
float TBPHSf = phaseVal;
TBPHSf -= EPwm2Regs.TBPHS.bit.TBPHS;
TBPHSf *= 65536;
EPwm2Regs.TBPHS.bit.TBPHSHR = (Uint16)TBPHSf;
update_MepScaleFactor();
}

I have configured both ePWMs for 500KHz frequency and 50% duty cycle. I have attached the oscilloscope screenshots for 3 cases of phase values

Case 1: Phase offset - 7 clock cycles, expected value of phase delay - 50 ns, Actual phase delay - 50 ns (red), ePWM2(green) lags in phase compared to ePWM1(yellow)

Case 2: Phase offset - 8 clock cycles, expected value of phase delay - 60 ns, Actual phase delay - 60 ns, ePWM2 lags in phase compared to ePWM1

Case 3: Phase offset - 7.6 clock cycles, expected value of phase delay - 56 ns, Actual phase delay - 44 ns, ePWM2 lags in phase compared to ePWM1

I can see similar behavior for up count mode as well. Can you let us know if anything is missing here.

Attaching the source code

2548.epwm_up_aq_cpu01.c
Fullscreen
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
//###########################################################################
//
// FILE: epwm_up_aq_cpu01.c
//
// TITLE: Action Qualifier Module - Using up count.
//
//! \addtogroup cpu01_example_list
//! <h1> EPWM Action Qualifier (epwm_up_aq)</h1>
//!
//! This example configures ePWM1, ePWM2, ePWM3 to produce an
//! waveform with independent modulation on EPWMxA and
//! EPWMxB.
//!
//! The compare values CMPA and CMPB are modified within the ePWM's ISR.
//!
//! The TB counter is in up count mode for this example.
//!
//! View the EPWM1A/B(PA0_GPIO0 & PA1_GPIO1), EPWM2A/B(PA2_GPIO2 & PA3_GPIO3)
//! and EPWM3A/B(PA4_GPIO4 & PA5_GPIO5) waveforms via an oscilloscope.
//!
//
//###########################################################################
// $TI Release: F2837xD Support Library v3.06.00.00 $
// $Release Date: Mon May 27 06:48:24 CDT 2019 $
// $Copyright:
// Copyright (C) 2013-2019 Texas Instruments Incorporated - http://www.ti.com/
//
// Redistribution and use in source and binary forms, with or without
// modification, are permitted provided that the following conditions
// are met:
//
// Redistributions of source code must retain the above copyright
// notice, this list of conditions and the following disclaimer.
//
// Redistributions in binary form must reproduce the above copyright
// notice, this list of conditions and the following disclaimer in the
// documentation and/or other materials provided with the
// distribution.
//
// Neither the name of Texas Instruments Incorporated nor the names of
// its contributors may be used to endorse or promote products derived
// from this software without specific prior written permission.
//
// THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
// "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
// LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
// A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
// OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
// SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
// LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
// DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
// THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
// (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
// OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
// $
//###########################################################################
//
// Included Files
//
#include "F28x_Project.h"
#include "SFO_V8.h"
//
// Defines
//
#define EPWM1_TIMER_TBPRD 2000 // Period register
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

Thanks,

Aditya

  • Hi,

    The TBPHSHR configuration does not seem correct. I wonder if you have already enabled the auto-calibration feature of HRPWM then it makes sense to configure the entire 32-bit Phase register (both integral and fractional part)  in one go by converting "phaseVal in Q16 fixed-point format" like this :

    EPwm2Regs.TBPHS = (uint32_t)(phaseVal * (float32_t)((uint32_t)1 << 16) + 0.5f);

    If my reply answers your question please click on "This resolved my issue" button located at the bottom of my post.

    Regards

    Himanshu

  • Hi Himanshu,

    Yes I have enabled auto-calibration feature.


    EPwm2Regs.HRCNFG.bit.AUTOCONV = 1;

    Configuring the entire 32-bit Phase register (both integral and fractional part)  in one go by converting "phaseVal in Q16 fixed-point format" like this :

    EPwm2Regs.TBPHS = (uint32_t)(phaseVal * (float32_t)((uint32_t)1 << 16) + 0.5f);

    also does not help. I still see the same behaviour.

    Thanks,

    Aditya

  • Hi,

    Okay but I think you need to provide me more information because your initial question is not very clear.

    You say  "Case 1: Phase offset - 7 clock cycles, expected value of phase delay - 50 ns, Actual phase delay - 50 ns (red), ePWM2(green) lags in phase compared to ePWM1(yellow)"

    But I think you meant expected delay to be 70ns as TBCLK is running at 100Mhz and also from the figure it seems Green leads the yellow one. So please revert with the correct information.

    And also if you notice, in all the cases the expected - actual is 20ns (i.e. 2 clocks). I looked at your code, you have enable Rising Edge delay of 4 half TBCLK as well so I am guessing that might affect your measurements.

    If my reply answers your question please click on "This resolved my issue" button located at the bottom of my post.

    Regards

    Himanshu

  • Hi Himanshu,

    That's expected delay of 2 clock cycles that happens due to the delay in loading the counter register. More details are provided in the e2e post

    LAUNCHXL-F28379D: Phase offset is always turning out to be more by 2 EPWM Clock Cycle. - C2000 microcontrollers...

    e2e.ti.com
    Part Number: LAUNCHXL-F28379D Hi all, I have a strange problem where in the Phase offset is always turning out to be more by 2 EPWM Clock Cycle. I have updated

    So I mention the expected delay as 50 ns considering the 2 clock cycles delay and thats what I measure actual value from CRO as well.

    Thanks,

    Aditya

  • Hi,

    Any updates on this issue? 

    Thanks,

    Aditya

  • Hi Aditya,

    As we are already working on this issue offline, can we close this thread over here.

    Thanks

    Himanshu

  • Hi Himanshu,

    Sure. Thanks. Let me know when you have an update on this.

    Thanks,

    Aditya