linuxdev, I am curious how you do “kernel OOPS from reading the UART controller register at 0x3110008”?
In your readout of 0x3110008, I see “Raw FIFO Entry: 0” and “Decoded FIFO Entry: 0”, don’t know if it means there is no FIFO so as mentioned in TRM in default the 16450 mode.
The easiest way is to log in to serial console, and run “dmesg --follow”. My serial console terminal is set to log. In another terminal read the address.
linuxdev, how do you read the address? Using “busybox devmem 0x3110008” or “devmem2 0x3110008”, anytime I do this will cause the system restart.
However, I got something by running my UART test program that shed some light on my problem using “dmesg --follow”:
[ 200.776909] serial-tegra c280000.serial: configured rate out of supported range by -1.18 %
[ 200.889049] serial-tegra c280000.serial: configured rate out of supported range by -1.18 %
[ 212.358680] dji_sdk_node[2616]: unhandled level 2 translation fault (11) at 0x00000018, esr 0x92000006
[ 212.368144] pgd = ffffffc1c3723000
[ 212.371594] [00000018] *pgd=000000022d0b6003, *pud=000000022d0b6003, *pmd=0000000000000000
The whole output is in the attached file.
“dji_sdk_node” is my serial communication test program, you can search “dji” to see if there is other concerns to my problem.
If as it says the rate is out of range, how can we change the range or limit?
dmesg_output.txt (69.1 KB)
I use both devmem2 and busybox devmem…both have the same result.
You may want to go here (go there, log in, then hit the link a second time to see document downloads):
[url]https://developer.nvidia.com/embedded/downloads[/url]
Search for “parker”, note that there are two Parker Series SoC documents. One is the TRM most people are familiar with. The second is an errata. Download the errata.
Search for “UART does not meet”. You will see some notes on UART issues, along with a “Workaround” section. Try setting ports to two stop bits.
I am still interested if NVIDIA could answer the question in #20 as to whether reading the controller register byte at offset 0x8 is changed by the DMA versus non-DMA driver use.
I read the errata, for UART1 it seems much more trouble than UART2, however, I at least got it work on UART1 @115200 and 230400 baud rate, while on UART2, no working at any baud rate. There is no parity in the configuration of UART2.
I think leaving parity out is best, but the part I was reading as more important is the use of two stop bits. Does the drone have the ability to use two stop bits?
Yes, you are right, and mostly for serial I use 115200, 8N1.
On the drone side, the only parameter I can control is the baud rate. I can only try on the TX2 side to have two stop bits, or maybe a higher baud rate (don’t know if it is possible).
Is there some specific hardware on the drone side you can post the information on? I’m curious about using unconventional methods to set it up to allow two stop bits.
The drone is closed and I don’t think there is easy way to do the set up. I will ask the drone company if it is possible to set up two stop bits on the drone.
For UART1 that accessible on developer board, there is problem of two stop bits. But for UART2 which is accessible on J130, there is no such problem, and for the parity problem, actually most standard serial now used is no parity, and I am sure on our code, it is configured to no parity. Anyway, there is no working baud rate, I tried all the drone accepts: 921600, 230400, 115200, 38400. Is the parity thing also should be set up in the memory IO register?
I got message from the drone company, they have a fault in there design that stop bits cannot be set, so it is hard coded with no parity and 1 stop bit.
As in the errata file, UART2 should work as it doesn’t have the problem of stop bit. I will test on the developer kit (where UART2 is pin out through the PCIe expansion slot).
The default on the Jetson is no parity…it’s the stop bits which seem to matter at higher speeds. The gist of it seems to be that timing issues start occurring more often at high data rates, and that two stop bits is a workaround for timing issues.
This is kind of a difficult issue, but if you have an extreme need, then you might consider putting your own UART at the remote end which acts as a bridge and does nothing but copy data through while converting from one stop bit to two stop bits. Or use a USB serial UART on the Jetson end which isn’t sensitive to the two stop bits issue (FTDI UARTs are generally supported without any special driver issues).
We actually use the USB serial UART now, it works fine. As we have more devices using USB ports, so we want to spare the serial one.
We want the UART2 to talk to done, UART1 is only used for test. Do you think UART2 also has stop bits problem? I test UART2 on developer board, today, not work. The TX is fine at 3.3V, but RX goes to 2.5V, don’t know what causes that.
I use UART2 to talk with an altimeter (lw20), it works fine with baud rate less or equal to 115200, up than that, there will be messy code, but still works until 460800.
Thanks linuxdev, it is greatly appreciated on helping and guiding me figure out the problem.
I’ve seen issues where the level converter from 1.8V to 3.3V doesn’t quite do all that is needed. It may be the level converter at issue since normally it is 1.8V…the jumper at J24 ships set to 3.3V, some I/O is actually 1.8V, and this is where those optional level-shifted interfaces get set to one or the other. I suspect if you switch to 1.8V, then voltage drops down to 2.5V won’t occur (well…it’ll actually be 1.8V). I’m not sure how the level shifter contributes to maximum speed, but it may be that using 1.8V would improve maximum speed. This may not be particularly useful if other I/O you depend on also shifts to 1.8V.
I all UARTs (not just Jetsons) have an upper limit which two stop bits would help improve.
Just FYI, FTDI and a number of other manufacturers make easy-to-design-with serial UART chips for low cost and with much in the way of documentation. A very small and light board could be created which has a single USB connection and multiple serial UARTs. I’m not saying this would not take a significant effort (since it would still involve USB), but the FTDI drivers and 16550 drivers already exist…so programming would not be as difficult as building these truly from scratch. Or just use a USB HUB…even 8 serial UARTs at 10Mbit/s would not get in the way of USB2.
We had tried USB hub, which leads in a lot of noise. This is why we choose J130 which has 4 USB ports.
Can you describe more about the noise and how it gets in the way? E.g., if it interferes with wireless control, with certification, so on? It may just be a case of removing the HUB’s plastic case and replacing it with a shield (you could do a test as simple as wrapping it with aluminum foil which is touching the ground of the HUB).
We have a lot sensors and controllers on our drone, we cannot see where the noise cause problem, when we use USB HUB, some of the them will not work. And we have tried many ways to remove the noise like using shield, none of them help.
This would be difficult to track down without the right equipment…I see what mean for wanting to avoid USB HUBs. On the other hand, it might be useful to try a test. I don’t know what the physical access is, but what I am thinking you might do is connect a HUB which leads directly away from the Jetson and everything else…place a large grounded shield (it could be cardboard covered with aluminum foil and grounded with an alligator clip…much less expensive than a spectrum analyzer) right next to the Jetson perpendicular to the USB cable leading away. Then see if you can detect one side of the shield having more noise than the other. This could potentially show whether some new clock source on the Jetson is the source of noise, versus something which is part of USB HUB topology (I don’t know where you see the noise…if the device being interfered with is hard connected then of course there is no way to move it around to see if it is seeing more noise on one side of the shield versus another).