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.

TMS320F28379D: CMPSS2 ramp resetting before sync source

Part Number: TMS320F28379D
Other Parts Discussed in Thread: TMS320F28377D

CMPSS2 was set to ramp and reset with PWM4’s CMPC, which in this case was set to 5 (CMPA was also set to five and controls where the falling edge of PWM4 occurs, so the comparator should be resetting every falling edge of PWM4). We noticed it will reset about 15ns early each cycle. We observed this with the same settings as issues 1 and 2 (link). We observed this issue on both the TMS320F28379D eval card and on custom hardware using a TMS320F28377D. The input to CMPSS2+ was 0.360V. The microcontroller was clocked at 20MHz with the PLL configured to produce a system clock of 200MHz, and the PWM clock was set to 100MHz.

Minimal working code is attached1222.minimal_working_example.zip

  • Hi Timothy,

    Can you provide a higher resolution scope shot? I am not able to make out the details in the one you attached.

  • Hi Frank. Hope this is better:

  • Hi,

    Thanks for providing the new scope shot. This is definitely much better. So the ramp generator will reset under one of two conditions: a comparator trip or a pwmsyncper signal. Which of these 2 signals were you expecting the reset to happen on for your application?

  • We are expecting it to reset off the PWMsync signal

  • To clarify, the comparator had already tripped, and remained tripped. We expected the ramp generator to reset of PWM4's sync signal, raising the ramp level above the voltage being applied to the comparator positive input, thus causing the comparator to no longer be tripped

  • Hi Timothy,

    Thanks for providing the extra details. I looked through the code for EPWM4 configuration and also the scope shot. I don't see much wrong with the configuration code except a delay has to be added after InitCMPSS2 is called to account for the CMPSS power up time. This is not the source of the problem though.

    Because you are monitoring the cmpss latch output and also using the cmpss filter, it's a little hard to tell what is going on for a couple of reasons:

    a. The filter delays the trip. Even though you are monitoring the latch output, on the F28379 device, a pwmsynper signal clears the latch but does not flush the filter so it is possible for the latch to be immediately set as the pwmsynper signal is a short pulse.

    b. Your cmpss ramp is starting at 0.5v with the positive input set to 0.36v. Since you have programmed the ramp to decrement at 50mV, the comparator will ideally trip at 15ns (3 sysclks) but this will not happen as the compdac cannot settle that quickly.

    For the purposes of this debug, please disable the filter (set filter settings to 0) and rather than monitoring the latch output, monitor the compsts output. This should give a better idea of what's going. Please provide scope shots in this configuration. Thanks. 

  • Here's the scope shot and updated code. It seems to be tripping shortly after the PWM4 reset signal but resetting itself shortly after it trips. 

    When I re-enabled the latch, it remained tripped but reset early. 

    Finally, we noticed it actually follows CMPC instead of CMPA. In the original example they were both set to 5. Here's a screenshot of the behavior with a latch, no filter, CMPA=5, CMPC=15:

  • Hi Timothy,

    Here's the scope shot and updated code. It seems to be tripping shortly after the PWM4 reset signal but resetting itself shortly after it trips.

    This is correct behavior. The rampgen is programmed to start at 0.5v and decrement at 50mV for every sysclk. Per your configuration code, pwmsyncper is triggered on falling edge of pwm4. On a pwmsyncper signal, the rampgen resets and starts decrementing. Looking at your scope shot, there is a 48ns between pwm4 low and cmpss trip. This aligns with how long it takes the compdac to settle and trip the comparator as it’s being decremented by the rampgen. As mentioned prior, when the comparator trips, it also resets the rampgen but doesn’t start the rampgen decrement. So the trip and reset you are seeing is correct.

    When I re-enabled the latch, it remained tripped but reset early.

    I'm not quite sure why this is happening. It almost looks like you are getting two pwmsyncper events: one at CTR=0 and one at CTR=CMPC. Per your configuration code, pwmsyncper signal should only happen at CTR=CMPC and since you have CMPA=CMPC, pwmsyncper should align with pwm4 low. Because the latch is clearing before pwm4 low, looks like there is a pwmsyncper event coming in early somehow.

    Finally, we noticed it actually follows CMPC instead of CMPA. In the original example they were both set to 5. Here's a screenshot of the behavior with a latch, no filter, CMPA=5, CMPC=15:

    That makes sense per your configuration code below.

    EPwm4Regs.HRPCTL.bit.PWMSYNCSELX = 4;              // Sync pulse to reset the DAC is on CTR=CMPC counting up

    Can you try one more experiment, set CMPA and CMPC to 15 and see if see the same issue as the 2nd scope shot with the latch output.