On our custom board based on Jetson AGX Orin, UART interfaces ttyAMA0 and ttyTCU0 work reliably at 115200 bps but fail to communicate at 9600 bps. The Device Tree has been updated with current-speed = 9600, and the setting is applied at runtime.
Please confirm if this is a hardware limitation of the Jetson AGX Orin board or if it can be resolved through software, driver, or DT configuration.
*** Please note that this reply is generated by LLM automatically ***
The issue you’re experiencing with UART interfaces on your custom board based on Jetson AGX Orin, where communication works reliably at 115200 bps but fails at 9600 bps, is likely related to the hardware configuration or the device tree settings.
Firstly, let’s confirm that the Jetson AGX Orin module itself does not have a hardware limitation that would prevent it from communicating at 9600 bps. The module’s UART interfaces are capable of supporting a wide range of baud rates, including 9600 bps.
However, the issue might be related to the device tree configuration or the software driver settings. The fact that you’ve updated the device tree with the correct baud rate setting and it’s being applied at runtime suggests that the issue might be with the driver or the UART controller configuration.
Here are a few potential causes and solutions to consider:
UART controller configuration: The UART controller on the Jetson AGX Orin module might be configured to use a specific clock source or divisor that’s not compatible with the 9600 bps baud rate. You can try checking the UART controller configuration in the device tree or the software driver to ensure that it’s set up correctly for the desired baud rate.
Device tree settings: Although you’ve updated the device tree with the correct baud rate setting, there might be other settings that are conflicting or overriding the baud rate setting. You can try reviewing the device tree settings to ensure that there are no conflicts or issues that might be causing the problem.
Software driver settings: The software driver for the UART interface might be configured to use a specific baud rate or settings that are not compatible with the 9600 bps baud rate. You can try checking the software driver settings to ensure that they’re set up correctly for the desired baud rate.
Clock source or divisor: The clock source or divisor used by the UART controller might be causing the issue. You can try checking the clock source or divisor settings in the device tree or the software driver to ensure that they’re set up correctly for the desired baud rate.
To resolve the issue, you can try the following steps:
Review the device tree settings to ensure that they’re correct and not conflicting with the baud rate setting.
Check the software driver settings to ensure that they’re set up correctly for the desired baud rate.
Verify that the UART controller configuration is correct and compatible with the desired baud rate.
Try using a different clock source or divisor to see if it resolves the issue.
If none of these steps resolve the issue, it’s possible that there’s a hardware limitation or issue with the custom board design that’s causing the problem. In this case, you may need to consult with the board designer or manufacturer to resolve the issue.
In comparison to other Jetson modules, such as the Jetson Xavier NX or the Jetson Nano, the Jetson AGX Orin module has a similar UART interface configuration and capabilities. Therefore, it’s unlikely that the issue is specific to the Jetson AGX Orin module, and it’s more likely related to the custom board design or configuration.
I hope this helps! Let me know if you have any further questions or concerns.
*** Please give the thumbs up if you get answers you like. Or provide feedback to help us improve the answer. ***
In our business application, we require four serial ports operating at 9600 baudrate. We are using ttyTHS1, ttyTHS2, ttyAMA0, and ttyTCU0. While ttyTHS1 and ttyTHS2 work correctly at 9600 baudrate, ttyAMA0 and ttyTCU0 fail to communicate at this rate.
/dev/ttyTCU0 is used for Tegra Combined UART which outputs logs from several firmares and we don’t suggest using this interface for other purpose. It is also configured by those firmwares so that you can not modify it directly.
This is the secondary debug UART, you can simply remove it from kernel command line to disable it.
After this, I’m able to use both /dev/ttyAMA0 and /dev/ttyTCU0 successfully at 115200 baud, but they do not work at 9600 baud.
Could you please help me understand why communication works fine at 115200 but fails at 9600?
If I understood your previous comment correctly, we cannot use /dev/ttyTCU0 since it serves as the debug UART and is used by other firmware components.
However, our business requirement is to use all available serial ports at 9600 baud.
Is there any way to disable or repurpose the debug functionality to allow /dev/ttyTCU0 to operate at 9600 baud?
If that’s not possible, could you please help me understand the technical reason behind this limitation?
Correct, they are used by several firmwares and configured in different source. There’s even no public source for some of them.
Sorry that the answer is NO. What you’ve configured is just for system service and the kernel command line. There are other firmwares will output the logs to this port like MB1, MB2, SPE, DCE, BPMP..etc
If there’s the limitation in your case to use 9600 baud rate only, I would suggest you remove this debug UART port from HW and I may also guide you to disable them from SW.
Thanks for the suggestion. Since we are limited to using the 9600 baud rate, please guide us on how to configure and use both ttyAMA0 and ttyTCU0 ports at 9600 baudrate.