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.

TMS320F28035: Ramp generator reset during blanking window

Part Number: TMS320F28035


Hi, I'm working on a peak current control application using internal blanking window and ramp generator hardware blocks in the F28035. While configuring the ramp generator I ran into some problems. A current spike at the beginning of the period is blanked out with blanking window so it won't cause tripping, but it will trigger the comparator and cause the ramp generator to reset to its starting value for the rest of the period. The actual current ramp won't trigger the comparator again until current reaches RAMPMAXVREF level causing a wider pulse and possibly some fast width changes. How is the ramp generator intended to be used with the blanking window enabled?

Best regards
Pauli

  • Pauli,

    The ramp generator resets when it receives a EPWM SYNC signal. You can configure the EPWM to generate its SYNC signal on matching CMPB instead of ZERO. If PWMSYNC is generated at or after the blanking window ends, the ramp generator should be able to run as expected.

    -Tommy
  • Thanks for the reply.

    Sounds like a good solution, but as far as I know the PWMSYNC can be set only to TBCTR = PRD or TBCTR = 0 using the PWMSYNCSEL bit. Is there some other way to set it to match on CMPB?

    Also I think it might be a bad idea to move the sync past the blanking window end because then the leftover of the previous ramp could make a false trigger on the next pulse extremely early. At or just before the end of blanking should be fine.

    -Pauli

  • Pauli,

    My apologies, you are right.  I was looking at the SYNCOSEL register description.  Some newer devices like F2807x do have the flexibility to generate PWMSYNC on CMPC/CMPD, but not on F2803x.

    I suppose that your next option would be to generate the PWMSYNC using another EPWM that is phase-shifted (by blanking window ticks) from your active current control EPWM.

    -Tommy

  • Thanks. Need to dedicate an extra PWM for it, but otherwise sounds like a good solution.

    -Pauli
  • A little bit of continuation for this thread.
    So, I have an extra PMW (PWM4) configured for synchronizing the ramp start after dead band and blanking window. I'm using the following formula to calculate the needed phase value:

    EPwm4Regs.TBPHS.half.TBPHS = EPwm4Regs.TBPRD - (EPwm2Regs.DBRED + BLANKING_WINDOW) + 3;

    +3 is needed to make sure the ramp starts before the blanking window ends. If the ramp starts late then the leftover of the ramp will trip next pulse at beginning. This can cause some random short pulses when we should have max width pulses constantly.

    Also, I had to set QUALSEL = 1 (SYNCSEL = 0) for the comparator because otherwise I could see a case where the comparator had triggered, but the output pulse was so short (observed from COMP3OUT) that it would not trigger a trip zone, but COMPSTS would still trigger the Ramp generator reset logic. Resetting the ramp causes it to stay at RAMPMAXREF for rest of period and would allow current to rise higher than it should. This is seen as rapid changes in the pulse width.

    After these settings everything seemed to be ok, until...

    As I'm using nonqualified comparator output (SYNCSEL = 0) for the trip zone logic I'm seeing some glitches in tripped pwm falling edge as described here:
    e2e.ti.com/.../2052360

    We decided to use larger QUALSEL to clean up these. But if I try to set QUALSEL > 1 and SYNCSEL = 1 the comparator output gets delayed and it can reach over after the blanking window and trigger trip zone early on the next pulse. I'm back at the original problem that some noise spike during blanking window may trip the next pulse early and cause a random short pulse. This time increasing TBPHS doesn't help.

    I'm out of ideas what to try next. It seems that I'm constantly forced to find various workarounds and struggling to get multiple HW features working at the same time. Am I doing something strange with my setup here?

    -Pauli

  • Pauli,

    I have very limited hands-on experience here, but I would think that you are taking the right approach by using the same QUALSEL signal for both resetting the ramp and tripping the EPWM.

    Do you have any insight into what is causing the comparator to trip during the blanking window? Is it random noise or is the sensed current hitting the RAMPSTS value near the end of the PWM cycle?

    If it's random noise, we can consider ways of increasing the effective comparator hysteresis for better noise immunity.

    If it's sensed current that is tripping late in the cycle, the approach may be to reduce the maximum duty cycle by a few SYSCLK periods.

    -Tommy
  • Thank you for your reply.

    I'm not sure what causes the tripping. All I know is that we are seeing some unexpected changes in the PWM width in the actual application. Usually a single extremely long or short pulse compared to others. I'm testing this on a docking station with just a variable power supply or some other simple means as the peak current signal. I'm trying to make sure there are no edge cases that could cause a false tripping or that the trip doesn't happen at all or comes late.

    I've found that if the ramp reset position is too late (after blanking window end) the ramp continues into next half cycle and then a low peak current can trigger trip zone too early. And if ramp reset is too early then a trip during blanking window resets the ramp and causes the real current to reach RAMPMAXREF late. I'm trying to make sure none of these cases are possible to happen.

    I understand that my test setup may not be totally realistic, but it's hard to test otherwise. Any ideas how to test and make sure that the trip zone, blanking window, ramp generator and all are working correctly are welcome? Now it is very laborious and the system seems to break easily. Confidence in the system isn't very high.

    Anyway, I found that moving the ramp reset a bit earlier by increasing TBPHS does help after all. Now I'm using:
    EPwm4Regs.TBPHS.half.TBPHS = EPwm4Regs.TBPRD - (EPwm2Regs.DBRED + BLANKING_WINDOW) + 10;

    When I increase QUALSEL to 4 and enable SYNCSEL I see that the COMP3OUT signal gets delayed and also wider. Then there's the additional delay from COMP3OUT to actually triggering the trip. So, with all these delays, the ramp reset needs to be quite a lot before the blanking window ends. Otherwise the trip will happen at the start of the next PWM cycle.

    This is ok, I guess. But if the reset gets too early (with a shorter blanking window for example) then I'm back with the problem of the ramp resetting during blanking window.

    There's still something strange happening on the comparator output when the peak current level is close to the RAMPMAXREF value, but fortunately the tripped pulse is ok.

    -Pauli

  • Pauli,

    I think this makes a little more sense given that you are using an adjustable power supply for the input. It is not difficult to put the system into bad boundary conditions when the input voltage and EPWM outputs are not linked through a control loop.

    I'll ask some experts here to see if they have recommendations for the bench setup.  Would you be interested in evaluating peak current control using an existing hardware kit?

    -Tommy

  • Thanks.

    What hardware kit would you suggest? If you mean the TMDSHVPSFBKIT, then I think it would not help us much since it's using F28027 which doesn't have a CLA.

    What comes to the bench setup, A miniature version of the actual converter would be great, but a lot of effort, I think. I've tried to use PWMs and RC-filters to simulate the ramp behavior with some success. I'm thinking of doing some kind of DIY waveform generator syncronized by the PWMs, to test the peak current and also simulate some possible noise spikes.

    -Pauli

  • Pauli,

    Yes, the TMDSHVPSFBKIT is probably the best option for peak current evaluation.

    As you have noted, the F28027 does not have CLA, but it is a code compatible subset of F28035 so anything that is developed on F28027 should port easily to F28035 when the custom board is available.

    -Tommy