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.

DRA829J: PADCONFIG: RXACTIVE and TX_DIS meaning and purpose

Part Number: DRA829J
Other Parts Discussed in Thread: DRA829, SYSCONFIG

Dear Ti-Team,

while working on DRA829 pin multiplexing and analyzing the existing TI SBL code, we could not really understand the purpose and meaning of the following PADCONFIGxx registers: TX_DIS and RX_ENABLE.

Could you please explain them a bit including use case. And what is also not completely clear is if values of these registers depend on each other or not, i.e.:

- RX_ACTIVE = TX_DIS (if RX is active, then TX is disabled and vise a versa)

We've checked SysConfig Tool as well, and look like that TX_DIS is not set there at all.

Regards,
Dmitry

  • Hi Dmitry,

    Due to a holiday in India, half of our team is currently out of office. Please expect a 1~2 day delay in responses.

    Apologies for the delay and thank you for your patience.

    - Fabiana Jaimes

  • Hi Dmitry,

    I would request Kyle to help here.

    Regards,

    Brijesh

  • Hi Brijesh,

    thanks for your reply.

    After looking different E2E threads, I have a feeling what is behind, but it would be great if TI can confirm it:

    RX_ENABLE: pad receiver circuitry, in simple words if enabled, we may read back the pin state; not mandatory to be used

    - TX_DIS: has to be cleared for pins configured as output to allow a pin setting to a desired state via GPIO_SET_DATAxy/GPIO_OUT_DATAxy register.

    Regards,
    Dmitry

  • Dmitry,

    Your basic understanding is correct.

    For background, an IO buffer connected to one pad (bidi on the pin) has an independent Input buffer and an independent output buffer.  The PADCONF regs can independently enable or disable the input path (RX_ENABLE) and the output path (TX_DIS).    This might conceptually be done to minimize power consumption (though it's really negligible).  Or as another example, you may want to "guarantee" that a particular GPIO is limited to functioning as an input (RX_ENABLE=1) and should never be allowed to "accidentally" drive an output (TX_DIS=1) (though "accidentally" having GPIO to drive an output can only happen in the case of a software bug)

    Once those two buffers are enabled, then the MUXMODE dictates which IP can dynamically control the corresponding IO.  

    If for example you're in GPIO mux mode ...

    At any given instant the output path can be high-z or actively driven.  If you tell the pin to act as an output, then the GPIO module drives the "output_enable" of the IO buffer (making it "not" high-z) and the output value from the GPIO module is driven on the output *and* reflected back on the input path if the RX_ENABLE is enabled.  And the GPIO IN value will reflect the state of the output value.

    If the RX_ENABLE is "disabled" then you would not see the GP In reflecting the GP Out.

    Similarly, if TX_DIS=1 then the GPIO "output enable" is gated off and regardless of what is set in GP OUT will not reflect on the output pad.

    Regards,

    Kyle

  • Hi Kyle,

    thank you for the perfectly clear explanation.

    Thread can be closed.

    Regards,
    Dmitry