I am working with a SOM mounted on a carrier board running Ubuntu 14.04 with the generic 3.13 kernel.
While testing out the peripherals, I hit a problem with serial communication.
Basically, I can transmit data from the custom platform to an external Linux machine, but I can not properly receive data from the external Linux machine to the custom platform.
Through my research I have messed with all sorts of BIOS settings, baud rates, hardware flow control, parity, etc. Nothing has worked. Most info I have found online just says "Make sure your baud rates and other settings match", and they do. It is not my first time working with Linux serial ports. But it is my first time encountering a problem like this.
Does anyone have any suggestions, recommendations, or has anyone ever seen an issue like this before?
More info: We are running a quad-core Intel Atom micro with a custom serial breakout interface. The serial port is at /dev/ttyS0.
EDIT (clarification):
If I set up a session in Picocom or Minicom, I can send characters from our custom platform (running Ubuntu 14.04) to another Linux PC (also running Ubuntu 14.04). However, if I try to send characters from the Linux PC to our custom board, I sometimes get nothing, and other times get unrecognized characters (they show up as bubbles with question marks in them).
I can also simply echo a string to /dev/ttyS0 on the custom platform and receive it on the Linux PC. I just can't get it to work the other way around.
Related
On Windows (either native or running on a virtual machine from a Linux host), I can open a serial port in 8N1 mode and my desired speed of 921600 bps, and an incoming test string arrives fine from an external hardware device: HELLO WORLD.
On Linux, however, with same serial configuration I can only get slightly garbled text: H�LLO �OR�D.
However, lower baudrates (such as 460800 bps) work fine in both Windows and Linux. So by using 921600 bps I'm clearly hitting a speed maximum, imposed by some component of Linux.
Why does this happen? Does Linux have a default limit on serial baudrate? Is there anything I should configure to enable baudrates higher than 460800 bps?
Some more details:
The external device's serial output is connected to the computer via a CH340G-type serial-to-USB converter.
Tested software is TeraTerm and PuTTY on Windows, picocom, minicom, and screen on Linux.
Tested O.S. versions are Windows 7, Ubuntu Linux 16.04, and Ubuntu 20.04.
As mentioned (but it's worth repeating it), the text can be read fine if opening the serial port on Windows running from a VirtualBox virtual machine, from the same Linux host that is not able to cope itself with the mentioned baudrate! I guess this works because VirtualBox simply does a USB device passthrough, so whatever limits Linux has, they don't apply to the virtualized Windows.
In theory, my Linux seems to support the requested speed: the file /usr/include/asm-generic/termbits.h contains the definition for B921600 (together with lower ones such as B460800, and lots of other higher ones that go up to B4000000).
There is/was a bug on the CH340 driver.
Apparently, the baud rate error for 921600 bps was more than 7%. I guess that's what you might be experiencing.
I don't have any such devices so I did not research this further and I'm not sure if the patch or patches written to fix this issue ended up on the mainline kernel.
You will have to go here and find out yourself.
Received my Jetson TK1 yesterday. After unboxing it and configuring the Linux GUI, rebooting the device with a mouse (cordless) attached to its USB 3.0 port takes it to some sort of Command line page where it probably loads some files and then the screen starts printing " [ . ] ". Nothing happens beyond that until I restart the board without any USB peripheral and then the device boots into the normal Linux GUI. Unable to figure out what's wrong with my board and why is it not working properly.(I am a newbie to LINUX)
P.S.: Connecting the monitor via HDMI after switching on the device gives no visual output, just a blank screen. Is it possible to connect the device via network adapter for remote access even it the screen is running blank?
The question is quite old, but as some people might get frustrated with it, I'll provide the answer for most probable cause.
Upgrading the board running 19.X release causes libglx.so to be corrupted. The issue have been actively discussed on NVIDIA forums and the best way to solve it is to upgrade to 21.X.
Otherwise, you can try recovering the libglx.so in the usr/lib/xorg/modules/extensions/ from Tegra124_Linux_R19.3.0_armhf.tbz2.
Could you possibly provide a bit more information about your situation.
Are you able to go to command mode by pressing 'CTRL+F1' or 'CTRL+ALT+F1'?
If that works, it means your Jetson operating system is working but only the GUI is not working properly.
Yes, You can use ssh to your Jetson (what I do) if only the GUI of Jetson is broken and your OS is working properly. Note that in order to do so you need to know ip address of your Jetson and perform some possible router configuration.
Note: Sometimes if you have a USB device connected to your system (jetson), the jetson might mistakenly assume the USB is storage type and therefore tries to boot up from the USB. This leads to failure since it can not load any OS of the USB. (I'm not sure if this is the case for you)
I have a windows XP based computer that is connected (peer 2 peer style) to a Windows 7 based computer. The goal is file transfer between the two.
Here's hitch one, the connection between the two computers is via USB. Ethernet is not an option and completely off the table for this situation, we're stuck with USB (Windows XP computer hardware configuration is inaccessible save for the USB hub). We do have the ability to install software on it though.....same situation goes for the Windows 7 machine
Here's hitch two, The solution MUST be implemented such that file transfers can be accomplished via DOS command terminal from the Windows XP based computer...so no bridge cable and "GUI dragging of files" is allowed. A bridge cable driven by DOS command line..now that would be a solution but have yet to see one.
Here's some buzzwords I have accumulated through some lengthy google research that might help explain where I believe I'm heading.
usbnet
RNDIS
PuTTY
plink
FTP server
I would like to ask how the IT experts would handle this, what software is needed on which end and what kind of configurations could I expect to have to deal with. I am a bit unsure about the whole ethernet over USB thing as it applies to this peer 2 peer situation and would welcome any advice.
I have an Ada program that communicates with an Intellibox Basic(a box that allows you to control trains) that is connected via USB.
Under Windows, I had to install a specific Serial driver (CP210x USB to UART Bridge VCP). With that driver I can communicate perfectly with the box. That means sending commands to the box.
Under Linux I'm communicating via /dev/ttyusb0 and I'm able to get messages from the box, but I can't send commands to the box. Nothing happens. I don't get an error or something.
Is the behavior of GNAT.SerialCommunication differently on Linux ? The program is the same. Do I have to setup certain things to get it to work on Linux ?
For example: A typical 2-byte command has the Command as the first Byte and the CRC check as the second one.
I had trouble with Serial_Communication at some point, where it turned out to be a problem with hardware-handshake being enabled in Linux. It's hard-coded in g-sercom.adb, look for "CRTSCTS". If your Intellibox does not use hardware handshake, Write() will block.
I believe I solved it by removing the CRTSCTS mask from the flags.
I'm trying to write a linux driver to a device that i have the windows driver of (Similar to the case described Here, but a different device)
I'm using Libusb for the communication on the linux side, and SourceUSB as my USB sniffer (on the windows machine). Now I think I've replicated the controls and bulks properly, but I can't really test the linux log against the windows one. I'm running Ubuntu 12.04 on a VM.
So my questions are:
Is there a multiplatform logger? That could really simplify the log compare process.
When I attach the USB device to the VM - I get the VM driver in Windows. Sniffing this device gives me exactly what the device sees, right? I mean - Is this where I want to sniff?
EDIT:
I've compiled my application on windows (libusb is cross platform - A big thanks to libusb developers who did such a good job) and my application worked properly.
When sniffing the VM driver while running my application on linux, I see the requests to the USB as VENDOR_DEVICE instead of CONTROL_TRANSFER and BULK_OR_INTERRUPT. This seems to be the problem if I understand correctly, since this is what the device "sees".
So I guess my problem now is why does Linux sends my requests as vendor.
ANOTHER EDIT: Problem solved:
Listening to the VM driver gave me the wrong requests (I was listening to the VM driver traffic, not, as i wanted, the traffic of the my USB linux driver
Libusb is perfectly multiplatform. It took me a few minutes to get my code to compile under windows, and from there it was pretty easy to debug and compare logs
You can use Wireshark to capture USB traffic. This page explain how to do it for Linux and Windows : CaptureSetup/USB