Since three days I’m looking an answer in this forum, but nothing worked, so I open this topic.
I’m using the Jetson TX2, with the board LI-TX1-CB, which I try to connect to a flight controller (Pixhawk) by TTL/UART provided by the J17 port (4 pins).
I doubled/tripled check the wiring, RX->TX, and TX->RX, GND->GND, from both controller. Besides, all the baudrates are set (115200 in this case). Both are using 3.3V TTL.
The pixhawk by itself worked already with a Raspberry Pi, or another PC, when I run the mavlink protocol communication.
But with the same wiring, impossible to make it work with the Jetson. I tried to make a simple communication with an FTDI cable to a PC, but no result too.
I’m using the port /dev/ttyTHS2 (which is linked to J17 as I understood). I already tried other port like /dev/ttyTHS* or /dev/S*, in case of.
The Jetson version is : R28.2.1 (From Date Thu May 2018). From what I read, this version is supposed to make the J17 work properly.
Is anyone had the same problem ? If so, I would appreciate some ideas to unlock the situation !
Thanks for the reading,
For the wiring, you can check the board here.
[url]Redirect Notice
I know nothing about that board, but you do need a different device tree whenever you switch carrier boards. Is this a dev kit carrier?
A good way to test a serial UART port is loopback. If you tie TX to RX (and if flow control is used, then also CTS to RTS), then a serial console program (my favorite is gtkterm), then you know both sides of the conversation are set to the same value (a port will never disagree with itself, but might have an incompatible setting relative to some other serial port). If it works, then typing in will echo what you type; if not, then either nothing will echo or the echo won’t be what you typed.
An example of talking to ttyTHS2 (J17) in loopback:
sudo gtkterm -b 8 -t 1 -s 115200 -p /dev/ttyTHS2
A subtle point here is that I used “sudo”. If the user talking to the port is a member of group dialout, then sudo isn’t needed. If a port use is attempted with non-root and non-dialout, then permission would be denied.
I have done the UART port loopback, and nothing is printed in the gtkterm…
For the configuration, I followed this instruction (I will attach it to this message).
I suppose the tree has been changed, but I have some doubt now.
What I had to change :
Replace tegra186-quill-p3310-1000-c03-00-base.dtb and use ./flash.sh (which, as I understood, changed the tree, right ? Because then, the USB port is OK.)
replace /boot/Image
replace /boot/zImage
add a .tgz file in /lib/modules, then unzip it.
I will try to upload the last kernel from the instruction. I let you know. Instruction.txt (5.41 KB)
Since gtkterm loopback did not work, then it tends to imply the device tree is not correct (or that the port is for a different UART). I can’t answer questions specifically on other carrier boards, but keep in mind that the device tree can change which pins are a UART or something else, and that when the carrier board layout changes, then the device tree needs to change as well since the old wiring is now modified.
It was only on older releases where the kernel Image could be changed in “/boot” and the running kernel would change (and on all of the 64-bit systems zImage was not used). The same is true for device tree where it used to just be a file in “/boot”, but the more recent releases require flashing to a partition (stages earlier than U-Boot have begun to need that information, and those earlier stages can’t read an ext4 file system).
For that Instruction.txt file this looks correct in that it uses flash options to update device tree, but I suspect the part about copy of Image and zImage to be invalid and to also require a flash option. The official L4T documentation would still be correct even on another carrier board…what would differ is that you’d be using the Image and device tree files for the alternate carrier board.
The modules part might be correct, but I have not tried. What you have there tends to imply that the modified kernel will result in “uname -r” of “4.4.38-tegra-leopard”, but I can’t swear to it without actually seeing where the modules unpack. The stock L4T kernel itself is version “4.4.38”, and has CONFIG_LOCALVERSION of “-tegra”, and thus looks for modules in “/lib/modules/4.4.38-tegra/”. If it is correct that this alternate kernel is version “4.4.38” and has CONFIG_LOCALVERSION of “-tegra-leopard”, then it implies the modules would be found in “/lib/modules/4.4.38-tegra-leopard/”.
What directories do you see in “/lib/modules/”? “4.4.38-tegra/” is expected, anything else is a customization. What do you see for “uname -r” output?
The modules would need to be complete in “/lib/modules/4.4.38-tegra-leopard/” since the “uname -r” matches this. If you are missing any modules when booted to this kernel, then that is where they would go. I assume the “.tgz” is just an original source of files. The “4.4.38-tegra/” directory would be from the original unmodified kernel…you could leave this there in case you ever plug the module into a dev board again (even so you’d still need some changes, but the kernel modules would already be set up).
You might want to browse and compare the “4.4.38-tegra-leopard/” and “4.4.38-tegra/” subdirectories since the leopard version would be a superset of the tegra version.
In theory there is more than one device tree file which might get used depending on configuration, and I can neither validate nor invalidate the use of “tegra186-quill-p3310-1000-c03-00-base.dtb”. However, during flash you would have seen this file being used if it is the correct one. Here is a modified version of the original flash command which would also log the device tree flash (if you flash again you can log it to be certain of what was installed):
The flash.sh must be from the same driver package version as is installed.
Can you confirm that the device tree you used in place of “tegra186-quill-p3310-1000-c03-00-base.dtb” was actually installed (and installed with the same flash.sh software which created the original install)? Device tree is highly likely the reason the port isn’t working as expected.
If you’re using a custom baseboard, and that baseboard isn’t 100% compatible with an existing Jetson product, then the vendor of that baseboard should supply complete instructions on how to flash the system to use their baseboard. This may be as simple as a document containing the required steps to modify an NVIDIA L4T release, or a complete customized L4T package. If the vendor publishes instructions rather than a custom SW distribution, make sure to start with the correct NVIDIA L4T release that the instructions are based on; things can change between L4T releases.
The log does verify the dtb used is “tegra186-quill-p3310-1000-c03-00-base.dtb”. Check the loopback test again.
FYI, I have assumed this is a standard dev kit (J17 tends to imply that…but correct me if I am wrong because that would change everything). Some of the other hardware mentioned are the external components talking to the J17 UART.
I reinstall all the Jetson again, with the same version of the Jetson as the instruction said (R28.2.0, not R28.2.1 if I remember well).
I pushed again with “tegra186-quill-p3310-1000-c03-00-base.dtb” and did all the installation process. I tested the loopback, but sadly, it is not working.
@linuxdev : What do you mean by “standard dev kit” ?
In the documentation of the board LI-TX1-CB, the UART port is described as J17.
I’m going to contact Leopard to check if they can do something. Thanks anyway !
If you have still idea to fix it, I’m always taking it =)
The carrier board the module mounts to when sold by NVIDIA, not as a module, is the “developer kit”. Using a different carrier board with the module implies not a standard dev kit. Device tree must differ for non-dev-kit carriers…and of course the device tree must not differ from the default flash if the dev kit carrier is used. The combination of module and carrier board is what determines device tree…if you are using the dev carrier the answer differs from another carrier.
Each manufacturer of a carrier board publishes a “board support package” (BSP) which is basically a device tree in one form or another.
I don’t know if J17 is the same UART on the non-dev carrier as it is on the one you are using. It could be, and often many features of an alternate carrier board match the dev carrier, but it isn’t 100%. Perhaps J17 isn’t ttyTHS2 on this board? The manufacturer could answer that.
