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.

ePWM setup sequence

Hi,

On my Piccolo 28035 board, I first setup the GPIO for ePWM function, then I setup the PWM module.

I have observed that by setting the GPIO to ePWM function, the IO is pulled active low.

Only after setting up the PWM Module, it is working as PWM.

So for active low PWMs, this is a problem - they are active between GPIO setup and ePWM setup.

Is the recommended setup to first initialize the ePWM and then set the GPIO to peripheral function / PWM?
This is different than in the examples.

Is the PWM really forced low after setting up the IO for PWM function? Is there no way to keep it in tristate mode (and so let the external pull-up / pull-down determine the PWM direction)?

  • Hi,

    I think that the initial pin setup after reset is GPIO-Input, so you need to have the appropriate pull-ups/pull-downs at startup no matter what.

    One way you could do is to first setup the PWM module and force a SW trip or play with the AQCTL registers to ensure your PWMs are in the off state, then configure the pins as PWM instead of GPIO.

    If you setup the GPIO registers first, you may get the case you noticed.

    Regards,

  • Yes, after reset, I get tristate at the pin (GPIO input), so with the external pullup, it is high.

    But after setting the GPIO mux to PWM function, it is forced low although the PWMModule is still at default state (which is 'do nothing' in the AQCTLA, AQCTLB registers).

    Why this?

    I can avoid this by first setting up the PWMModule and then the GPIO mux, but I would like to understand what happens.

  • The EPWM outputs (before the GPIO MUX) appear to be reset to active low - although I have not come across any documentation that guarantees that they will start up in this state so it's generally not a good practice to rely on it.

    If you really need three state output you can get it through the trip zone module - or - you can use that module to force the EPWMx output high (or low). You can use either a hardware trip zone input pin (if you want external control) or software to force a trip zone event that puts your EPWMx output(s) in tristate. Then your startup procedure would be:

    10 Keep the EPWM as a gpio input during startup (relying on your external pullup). 2) Initialize the EPWM. Set the trip zone to force the state (high or tri-state). 3) Change the GPIO MUX to the EPWM. It will keep the state forced by the trip zone until you clear the trip and this state (active high or high impedance) should be compatible with what the GPIO output was prior to selecting the EPWM.

    See the EPWM documentation for details. The trip zone module is a really nice feature that is also useful for communicating events from the CLA to the CPU. It's well worth the effort to understand its function.

     

     

  • Thanks for the answer. Your solution helps avoiding my problem. But:

    Wally Ritchie said:

    The EPWM outputs (before the GPIO MUX) appear to be reset to active low - although I have not come across any documentation that guarantees that they will start up in this state so it's generally not a good practice to rely on it.

    That's what bothers me - the ePWM output state seems to be undefined or at least undocumented.

    I would really like to get a TI comment regarding this ePWM initial state - why it is low and not tristate and where this is documented.

  • Perhaps a TI employee can give you a more definitive answer but frankly I would hope that they are applying their time dealing with bigger issues like characterization, errata, and getting production quantities of TMS parts out the door.

    The ePWM PIN outputs states are fully defined in SPRUFN3C. At reset they are INPUTS and unlike the other GPIO's they do not have any pullups enabled and therefor are essentially floating, i.e. high-impedance, i.e. tri-stated. I suspect this is by design so that an external pullup or pulldown can be configured to accomodate clean startup of the system on reset before initialization code gets to run. (Personally, I'd prefer a weak pull-up on the chip but we never get everything we'd prefer ;)  ).

    As to the EPWM outputs before the mux, SPRUGE9C defines all of the register bits that have defined values on reset. You should assume that all other bits are undefined until you program them. This is not at all unusual.

    You have a lot of flexibility to synchronize multiple PWM's before you start up and you can use trip-zones as previously discussed to independantly control the outputs. You can manually put all the registers in any state you want and you can even use a software forced event (see AQSFRC) to set the outputs (before the mux) anyway you want. I can't offhand think of any useful thing at startup that you can't readily accomplish. You do need a pullup or pulldown to suit your system requirements but most people would prefer this over a pull-up in one direction or the other, especially since the pin may be used for other purposes in many systems.

    Basically, the initial state of PWM output bits (before the MUX) prior to setting up the PWM is irrelevant 99.999+% of the time. The defaults are unlikely to be suitable for anything but examples and you are going to have to setup the registers for your application anyway. This is also a far better programming practice. Minimize the number of things that you have to rely on to behave as documented and never rely on undocumented states that you merely observe. If you don't follow such practice you will inevitably be burned by future silicon revs.

    Best regards and good luck with your design.