Hello,
Please, I am facing an Issue since couple days and I have not got support so far and this is my second thread.
I have updated from R3.4 to R3.5 to fix the GPIO stuck on low issue and it fixed but now the UART is not working anymore in my 40 pins header, yesterday I tried to flash new Jetpack 6.2.2 and it still not working, I configured the jetson-io and everythings seems fine but still not working it works in loopback but not with other hardware.
Please, I wasted many hours just to try everything I found online but still the same issue.
I already made a question 4 days ago but without any support. Please, also check my original question and read the comments and I hope someone can help me.
So far as I know, if this is “/dev/ttyTCU0”, then this is not just a GPIO. That happens to be designed specifically for serial console logging/access only. Other UARTs, such as those which can be configured as “/dev/ttyS#” or “/dev/ttyTHS#”, are GPIO. The first Jetsons had serial console able to go to those, but stopping the console service alone made them available. This is not true for a ttyTCU0 since the hardware wiring itself is different. Are you trying to use “/dev/ttyTCU0” for your own purposes? If so, then I don’t think that can happen.
Incidentally, if you are using one of the GPIO UARTs, and if a flash has made something no longer work, then I suspect it is the device tree which is the issue (which won’t fix what you want if it is instead “/dev/ttyTCU0”). If it is in fact the device tree, then either (A) the original device tree was perhaps edited, and lost the edit, or (B) the carrier board itself is not an electrical exact match to the reference carrier board layout. The latter case (B) tends to use the carrier board manufacturer’s device tree (unless it is an exact match to the dev kit reference board). If this had been using a device tree from a third party design, then flashing with the NVIDIA software would have removed the edits to the device tree and only those parts which did match the original dev kit carrier board layout would work.
Are you trying to use “/dev/ttyTCU0”, or is it a different UART? Is this from a developer’s kit, or is it from a third party?
@linuxdev in my project I must use 2 UARTs, and as in ORIN I have only one, I decided to use /dev/ttyTHS1 and /dev/ttyTCU0, for /dev/ttyTCU0 I just stoped the services, and indeed it send some debugging info that is not effecting my work as I need to send few commands only. I dont think the problem with /dev/ttyTCU0 and I have not modified the tree in any way.
As of now, I tried Jetpack 2.1.2 and Jetpack 2.2.2 and jetpack 1.0 and all of them did not work in a way then I decided to go back and try jetpack 2.1 rev1, this is the best and more stable one and after testing the uart both are working as before however, the GPIO problem is still exist and I have to find a solution for it but it would be easier than UART, worth to mentioned, /dev/ttyTHS1 worked in all the version I mentioned before but only in Loopback not with other hardware and this prove it is not tree issue however, the uart is not configured in a way allowit to comunicate with other hardware only with iself.
@Kangalow 's video reminded me of something: What is the ownership of your “/dev/ttyTCU0”? Run “ls -l /dev/ttyTCU0”. Make sure it is dialout for group; if not, then you still have other software trying to own that device (and that sometimes accepts input to a console, it isn’t just output). It is possible that problems during boot could differ from problems at run time since serial use and setup in boot stages differs from that of when the Linux kernel runs; stopping the service only matters when the kernel is running. Regardless, if the group of ttyTCU0 is not what you expect, then you’re going to have surprises or missing or odd behavior of the port.
You might consider a USB or other add-on serial UART. If you think you might try an add-on UART, then you might describe your requirements in more detail, but you won’t find any “official” way to customize the ttyTCU0 port since it is dedicated in both hardware and software for serial console. You might also consider an SPI or i2c change, though I suppose the hardware you’re working with probably does not have that capability.
yes are right the owner of the port does matter, I have dialout in the groups and it works perfectly as I just need it for few times only during my whole run, also I cant use any add on cuz I am really tired of jetson boards and its bugs and I dont want to get into a new bug also my other hardware support only uart, I am already using I2c, usrts, gpios, pwm and I will add i2s soon. I consumed must of its ports.if you would need extra uart give this tcu0 a shot. Thank you for your reply