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.

Pull-up of a function pin: possible?

Dear experts,

I see here quite a few questions about GPIO configuration, so hope this one will be easy to answer.

We need to configure a pin R1 (ball or whatever) of AM335 as PWM. This is mode 3, according to the mux table.

The catch is that we also must set this pin to pull-up state so that it is HIGH when PWM is not driving it.

The pin must be output, pull-up and in mode 3.

But no matter what we do, the electrical state of the pin remains low.

Is this possible?

We have following statements in the dts file:

am33xx_pinmux: pinmux@44e10800 {

    pinctrl-names = "default";
    pinctrl-0 = <&clkout1_pin &mmc1_pins &wlan_pins>;

   i2c0_pins: pinmux_i2c0_pins {
   pinctrl-single,pins = <
      0x188 (PIN_INPUT_PULLUP | MUX_MODE0) /* i2c0_sda.i2c0_sda */
      0x18c (PIN_INPUT_PULLUP | MUX_MODE0) /* i2c0_scl.i2c0_scl */
      0xa0 (PIN_OUTPUT_PULLUP | MUX_MODE3)  /* THIS PIN <<<<< value 0x13 */

...........................

We tried also disable the pullup and changed the last line so:

      0xa0 (PIN_OUTPUT |  PULL_DISABLE | MUX_MODE3)  /* THIS PIN <<<<<  value 0x1B */

Please advise, is it possible to achieve our goal?

Thanks in advance,

S.

  • Please post what is the processor package - ZCE or ZCZ? Is this a custom board or one of the TI EVMs?

  • Saul said:
      0xa0 (PIN_OUTPUT_PULLUP | MUX_MODE3)  /* THIS PIN <<<<< value 0x13 */

    What is this line doing in the i2c0 pinmux section? You should place it in the PWM pinmux section.

  • Besides, R1 is the LCD_DATA0 pin, which is also the SYSBOOT0 pin. This pin requires an external pull resistor, because it is used to select the boot sequence. Please check what external pullup/pulldown you have on this signal.

  • Dear Biser,

    The system is this. It likely has ZCZ chip. The system's (SoM) vendor documentation does not mention the SYSBOOT thing, we'll check this.

    In their docum this pin is denoted as "I/OPU" which stands for input, output, internal pullup.

    Now why the mux pin is in pinmux_i2c0_pins section in the dtb file, I don't know, this file was created by some Linux consulting firm. I'll check this too.

    But basically the PWM works and everything else looks fine.

    Thanks,

    Saul

  • Saul said:
    The pin must be output, pull-up and in mode 3.

    Saul said:
          0xa0 (PIN_OUTPUT_PULLUP | MUX_MODE3)  /* THIS PIN <<<<< value 0x13 */

    Your statement and your mux configuration programming both correlate. However, they both have the same issue.  In particular, when you configure the mux mode to 3 (ehrpwm2A), then the ePWM module has control of the pad.  It is driving the state all the time.  Your pullup/down becomes irrelevant because it's over-driven by the PWM itself.  From the sound of things, when the ePWM powers up and is not yet programmed it drives a logic level low.

    If for example you kept the mux mode at its reset value of 7 (gpio input), then the pullup would actually do something.  So if you change your above configuration to use MUX_MODE7 then I think you'll see that the pin gets pulled high initially.  Of course, you will need to have a line of code somewhere to flip it to mux mode 3 at a later time when you want to let the PWM drive the signal.

    Another thought might be to setup the PWM such that initially it is running with 100% duty cycle (i.e. high all of the time).  That might be a little cleaner in terms of later you would simply make an on-the-fly adjustment to the duty cycle which is the normal way you would operate the ePWM.

  • Brad, thank you a lot, the 100% duty cycle seems to work. If you ever travel nearby, I owe you a beer!

    -- S.