• State
  • Locked Locked
  • Replies 7 replies
  • Subscribers 82 subscribers
  • Views 1221 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.

TMS320F28379D: Initializing ePWMs while TBCLKSYNC = 0

Mike Twieg1
Intellectual 390 points
Part Number: TMS320F28379D

Hi all,

For my application I'm using several synchronized ePWM channels, with a fairly lengthy initialization process to ensure that the output signals are perfect without any odd behavior during the first couple periods. I follow TI's advice by holding TBCLKSYNC = 0 while doing initializing all the registers, then write TBCLKSYNC = 1 to activate the ePWM operation (followed by a software force sync). However, I've noticed some things in the initialization routine don't work the way I expect. For example, I want to set the initialize the states of the PWM outputs by initializing the AQ module. Here's roughly how I try to do this:

// Disable TBCLKSYNC
EALLOW;
CpuSysRegs.PCLKCR0.bit.TBCLKSYNC = 0;
EDIS;

....

//init the AQ so that both pins are initially low
//ePWMB is inverted in DB module, so need to set B output HIGH
EPwm1Regs.AQSFRC.bit.RLDCSF=3; //set for immediate reload
EPwm1Regs.AQSFRC.bit.ACTSFA=AQ_CLEAR;
EPwm1Regs.AQSFRC.bit.ACTSFB=AQ_SET;
//assert a one-time force
EPwm1Regs.AQSFRC.bit.OTSFA=1;
EPwm1Regs.AQSFRC.bit.OTSFB=1;

....
// set up DB to invert B output of AQ
EPwm1Regs.DBCTL.bit.POLSEL = DB_ACTV_HIC; //This is where I observe my B pin going high.

... // register initialization is done // enable timebase clock 
EALLOW;
CpuSysRegs.PCLKCR0.bit.TBCLKSYNC = 1;
__asm (" nop");
__asm (" nop");
__asm (" nop");
__asm (" nop");
__asm (" nop");
//Perform a software sync
EPwm1Regs.TBCTL.bit.SWFSYNC = 1; //force all timebases to load from TBPHS
__asm (" nop");
__asm (" nop");
__asm (" nop");
__asm (" nop");
__asm (" nop");
EDIS;

However, the OTSFA operations don't seem to do anything. But I do see the ePWM1B pin go high when DBCTL.bit.POLSEL is written. In the debugger, it seems that if I manually set TBCLKSYNC any time after that, then ePWM1B goes low immediately, almost as if the OTSF operation was kept pending until then.

So what operations actually take effect when TBCLKSYNC = 0, and which ones will wait for TBCLKSYNC to be set = 1?

  • 0
    TI__Mastermind 24800 points

    Hi Mike,

    The TBCLKSYNC bit when set will start the time base counter (TBCTR) for all of the epwm modules within the corresponding CPU selected. Everything except the TBCTR of each module enabled in PCLKCR2 will still be clocked by EPWMCLK. This is why you see the dead-band taking effect and not the action qualifier settings. The action qualifier is dependent on the TBCTR count, but the dead-band module does not (it's meant to be a safety precaution in applications).

    Best Regards,

    Marlyn

  • 0 in reply to Marlyn Rosales Castaneda20
    Intellectual 390 points

    Thanks for the reply Marlyn,

    Marlyn Rosales Castaneda20 said:
    The action qualifier is dependent on the TBCTR count, but the dead-band module does not

    I can understand that many of the AQ's actions would be dependent on the TBCTR, since most of the events it handles originate from the TB and CC modules. But I don't think it's unreasonable to expect software force events to work independently of TBCTR, especially since the TRM states that software force events have top priority. Same logic would apply to the TZFRC operations. Are those gated by TBCLKSYNC as well?

    Anyways, what is the right way to go about initializing the AQ then? I've seen in other threads about PWM initialization that the proposed solution boils down to "just allow the first couple pwm cycles to give bade signals, but inhibit those signals from making it to the pins until they settle to the desired state" either by using the TZ or the GPIO mux settings, but I don't consider these to be acceptable solutions (GPIO mux settings aren't synchronous to the ePWM timebase, and I need to have things set up such that a TZ event triggers a fault-handling ISR). Maybe enabling TBCLKSYNC briefly during initialization just to allow the AQ settings to take hold would work? I haven't seen anyone else try this.

  • 0 in reply to Mike Twieg1
    TI__Mastermind 24800 points

    Mike,

    Mike Twieg1 said:
    Same logic would apply to the TZFRC operations. Are those gated by TBCLKSYNC as well?

    No, the TZFRC operations are not gated by TBCLKSYNC. These should still take effect even during your initialization. Like the dead-band submodule, the trip-zone submodule is meant to be configured to serve as a precaution for many scenarios. This will not be dependent on the time-base counter.

    Within you application are you trying to keep all of your epwm outputs low during the initialization process or until what point in your application? You are right that the GPIO mux settings aren't synchronous to the ePWM time-base, but you could always generate an interrupt after a programmable number of events, and change the gpio mux settings within that ISR. This should not interfere with your trip zone interrupt. Would this work for your application? 

    Best Regards,

    Marlyn

  • 0 in reply to Marlyn Rosales Castaneda20
    Intellectual 390 points

    Hi Marlyn,

    Marlyn Rosales Castaneda20 said:
    the TZFRC operations are not gated by TBCLKSYNC. These should still take effect even during your initialization. Like the dead-band submodule, the trip-zone submodule is meant to be configured to serve as a precaution for many scenarios. This will not be dependent on the time-base counter.

    Right, I understand why certain operations would be allowed before TBCLKSYNC, similar to why many registers require EALLOW. The problem is that the TRM doesn't seem to explain which operations are gated by TBCLKSYNC. Imagine if the TRM left out which registers are protected by EALLOW... that's sort of what I'm dealing with.

    Marlyn Rosales Castaneda20 said:
    Within you application are you trying to keep all of your epwm outputs low during the initialization process or until what point in your application?

    Until the TBCLKSYNC is set. At that point, I have numerous SOCs and INTs generated by the ePWMs, and all of those are set up to trigger ADC conversions, control ISRs, and CLA tasks. Immediately after TBCLKSYNC is set, I'm basically in "real time" mode. The CPU has to give priority to those control ISRs triggered by the ePWMs (the tripzone ISR is the only exception, and is allowed to interrupt and clobber the normal control ISRs). I need the PWM signals to not produce any cross conduction events. But cramming yet another initialization routine or ISR after entering "real time" mode is not an attractive solution.

  • 0 in reply to Mike Twieg1
    TI__Mastermind 24800 points

    Hi Mike,

    Thank you for providing your feedback about the documentation available. I'll submit a request to add more detail about which functions are gated by TBCLKSYNC and which are not to the next release of the TRM.

    Now, lets figure out a solution that will work for what you are trying to do. With your current setup, what is the issue that you see with not having the action qualifier force register take effect? In order words, if epwm output B is high during the initialization what effect does that have on your system? SOC events are meant to be triggered by time-base counter events which during the initialization should not occur. 

    Best Regards,

    Marlyn

  • 0 in reply to Marlyn Rosales Castaneda20
    Intellectual 390 points

    In my application I'm using both outputs of each ePWM channel to control half bridges. ePWMxA drives the high side FETs, ePWMxB drives the low side FETs. I'm using both outputs of the AQ for this, rather than allowing the DB module to create complementary signals from a single AQ output (I have good reasons). Also, in my application it is necessary to disable the pwm outputs, and thus the power electronics, and then later enable them again, without resetting the MCU.

    When disabling, I first force a oneshot TZ event, and then do all the various register accesses to stop the ePWMs from counting, etc. I've seen that sometimes, after when I go to enable the ePWMs again, that the AQ has gotten into such a state that both outputs initialize high, which immediately causes damage. I can think of a lot of possible causes for this (for example, if I stop TBCTR when it's in between CMPA and CMPB events). Hard to be sure, since the AQ states are not directly observable. Not being able to observe the sate isn't a big problem by itself, but if I also can't force the AQ into a known state... then that is a big problem.

    Another option I've considered, but not tested, is to use the SOFTPRES2 bits to soft-reset the ePWM channels, then totally redo the configuration from scratch. Does SOFTPRES2 just clear register values, or will it also clear internal states such the AQ, and SOCs and INTs and such? Does it depend on TBCLKSYNC at all?

    Regards,

    Mike

  • 0 in reply to Mike Twieg1
    TI__Mastermind 24800 points

    Hi Mike,

    You can use the SOFTPRES2 bits to soft-reset the ePWM module, this will clear register values and internal states of the AQ, SOC, and INTs. If something was already triggered before setting the SOFTPRES2 bits though this will still get executed. However, the soft-reset will prevent any new generation. You are right, you'll have to initialize the epwm module again and set the TBCLKSYNC bit as well.

    Best Regards,

    Marlyn