RS232 TXD signal glitch when system shut down

Hi~
Our project has an RS232 TXD signal glitch issue when the system shuts down. We fear it will cause some machines abnormal. This glitch was caused by power_en and com_tx(from Xavier SOM UART tx source) active low at the same time. Since we use the power_en pin to turn off the RS232 transceiver, If the power_en pin and com_tx are active low at the same time, this glitch will appear. Is it possible to delay the com_tx signal activating low after the power_en signal is active low ??


Thanks
Ken

Hi,
For information, do you observe the glitch on Xavier developer kit or your custom board?

Hi~
No, Because Xavier’s dev kit doesn’t have an RS232 transceiver circuit. Is it possible to control UART TX signal timing during system shut down?
We’re thinking of another solution. We’re thinking maybe we can design a GPIO pin to control turning off the RS232 transceiver before the system goes restart, suspend, and all of shut down case(HW shutdown/SW shutdown/Thermal shutdown). Is it possible to do that?
GPIO function step:

  1. system ready to restart, suspend, or shutdown.
  2. GPIO turn off RS232 transceiver before system do restart, suspend or shutdown process
  3. system start system do restart, suspend or shutdown process

Thanks
Ken

Hi, if you can’t observe same glitch on devkit, then it means the glitch is related to your RS232 transceiver only. I am not sure why this glitch (Tx is an output from Xavier) happen, maybe you should find out the source of it first. Or you can try not to use power_en for to turn off transceiver? Or as you said, you can use GPIO to turn off transceiver before system shutdown.

Hi~Trumany,
Do you know which driver controls the SHUTDOWN_REQ# pin? Our SW engineer needs to know this information to select a GPIO pin.

Thanks
Ken

It’s not programmable.

Hi~Trumany,
Do you mean SHUTDOWN_REQ* & SYS_RESET* cannot be programmable by any driver, because it is a hardware logic circuit??
If we want to use a GPIO pin to turn off the transceiver, this GPIO needs to know what time the system will enter the shutdown process and turn off the transceiver before the system enters the shutdown process. Do you know how to select a GPIO that can do this action?

Thanks
Ken

Hi,
Here is the behavior of devkit:

Source of SHUTDOWN_REQ: 
Software shutdown(by shutdown in UI or "sudo shutdown now") --> PMIC GPIO5 shutdown then also assert SHUTDOWN_REQ
Thermal overheat shutdown --> T194 SHUTDOWN_N 
VDD_IN power bad

SHUTDOWN_REQ assert issue OFF/ON cycle also will trigger SYS_RESET.
However, none of them covers tegra reset case like "sudo reboot". Thus, sw reboot is an exception.

Please take a look and check if you can apply the behavior to your custom board.

Hi~ Danel & Trumany,
Do you know which driver controls PMIC GPIO 5?? Our SW engineer needs to know it.

Thanks
Ken

Have you tried using SYS_RESET to turn off transceiver? It is later asserted than POWER_EN.

Hi~Trumany,
As I mentioned before, This transceiver output glitch is caused by the POWER_EN pin turning off the transceiver and the SOM UART TX signal transitioning low at the same time when the system starts the software shutdown process.

Since we planned to turn off the transceiver before all of our custom board power down, so we chosen the earliest power-down signal in the power sequence (POWER_EN pin). It cannot solve our problem even if we change the SYS_RESET pin to turn off the transceiver. We want to use a GPIO to turn off the transceiver before POWER_EN pin before the system starts the software shutdown process.

Our GPIO function as below step:
PMIC GPIO5 assert ->> our select GPIO turn off this transceiver → SHUTDOWN_REQ# pin assert → POWER_EN pin de-assert -->SYS_RESET# pin assert → turn off all of our custom board power.

Could you let us know which driver controls PMIC GPIO 5?? Our SW engineer needs to know it.
Thanks
Ken

Hi,

Which stage of PMIC control are you asking? The kernel has PMIC driver but some early stage bootloader also have PMIC configuration too.

However, only kernel is open source and some early bootloader is not. So we want to clarify the exact timing you want to control this GPIO.

Hi~
When I execute “reboot” or “poweroff” command, I need to get PMIC SHUTDOWN_REQ# signal as early as possible,

Do you know which driver controls the SHUTDOWN_REQ# pin?
Which files do I need to modify in the kernel??

Check the PMIC driver. MAX77620.