• State
  • Locked Locked
  • Replies 6 replies
  • Subscribers 83 subscribers
  • Views 227 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Original question:

TMS320F280049: CMPAHR setting alters rising and falling edge delay (not in the register but at the physical output)

TMS320F28379D: TMS320F28379D: CMPAHR setting alters rising and falling edge delay (not in the register but at the physical output)

MINHSUN LAI
Prodigy 20 points

Part Number: TMS320F28379D
Other Parts Discussed in Thread: TMS320F280049, C2000WARE

I encountered this issue during signal measurement. Although I found a related discussion on the forum" TMS320F280049: CMPAHR setting alters rising and falling edge delay (not in the register but at the physical output)", the problem remains unresolved. Are there any other solutions to fix this?

  • 0
    TI__Intellectual 1420 points

    Hi Minhsun,

    Can you provide the values you loaded to CMPAHR, rising edge delay and falling edge delay? And can you also specify the variation you are seeing in the rising and falling edge delays compared to the value loaded in CMPHR.

    Regards,
    Harisyam

  • 0
    Prodigy 20 points

    Hi Harisyam,

    Thank you for your response.

    Here are the values I loaded.

    CMPAHR rising edge delay falling edge delay
    256 68.2ns 72 ns
    0 68.2 ns 82 ns
    1024 68.2 ns 72 ns
    2048 68.2 ns 72 ns
    4096 69 ns 72 ns
    16384 70.6 ns 74.6 ns
  • 0 in reply to MINHSUN LAI
    TI__Intellectual 1420 points

    Hi Minhsun,

    I did not find a reported bug for the variation in rising edge delay or falling edge delay related to CMPAHR setting. In order to have a better understanding of the problem, can you share the complete configuration of your PWM or the code.

    Regards,
    Harisyam

  • 0 in reply to Harisyam P V
    Prodigy 20 points

    Thank you for your follow-up.

    As requested, I have attached the key parts of my source code. I am using the F28379D LaunchPad and the project is based on the C2000Ware example hrpwm_deadband_sfo_v8.
    When I try to insert code, it says "An error occurred. Please try again or contact your administrator."

    So I uploaded the file to my Google Drive.

    https://drive.google.com/file/d/1TJrGyonwgfeblQx0TaxXG2iiYUdwgC5f/view?usp=sharing

  • 0 in reply to MINHSUN LAI
    TI__Intellectual 1420 points

    Hi Minhusan,

    I will try to replicate this from my side and get back to you.

    Reagrds,
    Harisyam

  • 0
    TI__Expert 3140 points

    Hi Minhsun,

    This is a known architectural behavior of the HRPWM module—not a bug—and there are concrete steps to address it. Let me walk through what's happening and how to fix it.

    Root Cause

    The CMPAHR delay is applied after the dead-band module in the signal chain, contrary to what the block diagrams in the TRM suggest [1]. This means when you modify CMPAHR, you're shifting the final output edge (post-dead-band), which is why both rising and falling edge delays appear to change at the physical output even though DBRED/DBFED register values remain unchanged.

    Additionally, at every zero/period event in up-down count mode, the HR module undergoes a recalibration that bypasses the HR signal path for ~3 TBCLK cycles [1]. If your CMPA + dead-band delay falls within this window, you'll see glitches. The TRM's documented restriction should actually read: CMPA + DBRED/DBFED must not fall within 3 TBCLKs of zero or TBPRD [1].

    Required Fixes

    1. Write to BOTH CMPAHR and CMPBHR

    Since HRPWM adjustments are applied after the dead-band module, CMPAHR only affects Channel A and CMPBHR only affects Channel B—even in Active High Complementary (AHC) mode where B is derived from A. Every time you update CMPAHR, you must also update CMPBHR [2].

    In your ISR, the CMPAHR write is commented out and CMPBHR is never written:

    // Current code (incomplete):
    (*EPWM[PWM1]).CMPA.bit.CMPA = TimeBase * (1 - Duty1);
    // (*EPWM[PWM1]).CMPA.bit.CMPAHR = (frac * 256.0); // commented out
    // CMPBHR is never updated

    // Fix: Update both HR registers
    (*EPWM[PWM1]).CMPA.bit.CMPAHR = (frac * 256.0);
    (*EPWM[PWM1]).CMPB.bit.CMPBHR = (frac * 256.0); // Must match CMPAHR

    2. Confirm Up-Down Count Mode (Already Correct)

    Your code uses TB_COUNT_UPDOWN, which is correct. The dead-band module is not supported in HR mode when using up-count mode [3][4]. Users who have switched from up-count to up-down count mode confirmed this resolved their instability [3].

    3. Enable Half-Cycle Clocking for HR Dead-Band

    The TRM states: "High-resolution dead-band RED and FED requires Half-Cycle clocking mode (DBCTL[HALFCYCLE] = 1)" [2]. Your code currently has:

    (*EPWM[PWM1]).DBCTL.bit.HALFCYCLE = 0; // Should be 1 for HR dead-band
    This needs to be set to 1. Note that enabling half-cycle clocking changes the formula for your RED/FED delay values [2].

    4. Maintain DBRED/DBFED ≥ 4

    Your current values of DBRED = 7 and DBFED = 7 satisfy the minimum requirement that these values must be greater than 3 when using high-resolution dead-band [5].

    5. Avoid Forbidden CMPA Zones

    For your configuration (TBPRD ≈ 1000 at 50kHz with up-down count), ensure that CMPA + DBRED does not fall within 3 TBCLK cycles of zero or TBPRD [1]. If it does, you'll see transient glitches during the HR recalibration window. Calculate your specific forbidden ranges based on your TBPRD and DBRED/DBFED values.

    Summary of Changes

    Setting
    Your Current Code
    Required
    CMPBHR update in ISR
    Not written
    Must match CMPAHR every cycle
    DBCTL.HALFCYCLE
    0
    1 (required for HR dead-band)
    Counter mode
    Up-down ✓
    Up-down (correct)
    DBRED/DBFED minimum
    7 ✓
    ≥ 4 (correct)
    CMPA range
    Unchecked
    Avoid ±3 TBCLK of zero/TBPRD including DB delay

    The hrpwm_deadband_sfo_v8 example you're already referencing demonstrates the correct register configuration for combining HR duty cycle control with dead-band in symmetric mode [6]—but the critical missing piece in most implementations is the CMPBHR update and half-cycle clocking enablement.

    1. TMS320F280039C: Complementary high-res PWM pattern generation (TI E2E - Internal)
    2. C2000Ware: Dead-band module not working properly - gate drive signals overlapping (TI E2E)
    3. TMS320F28379D: Dead band unstable with non-zero TBPRDHR (TI E2E)
    4. F2837xD Technical Reference Manual - HRPWM Chapter
    5. F2837xD Technical Reference Manual - HRPWM Dead-Band Operation
    6. TMS320F28377D: Symmetrical complementary PWM outputs with HR and deadband (TI E2E)

    Thanks

    Srikanth