Python Serial Issue

Autonomous Machines Jetson & Embedded Systems Jetson TX2
#1

Hello,

I’m trying to interface a SIM7100A LTE module from SIMCOM. I installed the driver and I can see now ttyUSB0 to 4 on dev directory.

The issue is that my simple code which writes an AT command on serial port using python pyserial library and listens to the return doesn’t work.
In many cases it gets nothing, sometime it gets the respond but this cases are rare.
I tried Minicom and I can type AT commands on modem and get the respond from LTE module on the same port correctly. So I can make sure that the module is working, and the serial port settings are correct.

I also tried exactly same code on other system (Ubuntu 14 on my laptop and Ubuntu 16.04 on another processor iMX6)

My feeling is that the carriage return is different in TX2 environment.
I tried all of ‘\r’, ‘\r\n’ and ‘\n’ as new line at the end of the command but non of them are working.

Here is my simple code:

import time
ser=serial.Serial(port='/dev/ttyUSB2', baudrate=115200, timeout=1)
ser.write('AT\r')
while True:
        response = ser.read()
        print(response)
ser.close()
#2

What is the quality of the physical wiring? Length? Twisted pair? Shielded? If this is just regular wire you might try going to a quality twisted pair, e.g., from an ethernet cable. If the cable is long length, then you might try shortening it. Once you know signal quality isn’t an issue you can try logging the bytes (you’d want it to log binary data without any translation of bytes).

#3

The is no wiring, I attached the module to a mPCIe connector which is connected to a USB hub (I’m just using USB connections in mPCI and module is not a real mPCIe module).
I don’t think the connections is an issue, because, the module creates 5 ttyUSB (ttyUSB0 … 4) which ttyUSB2 is for serial AT command and ttyUSB3 for modem, I use ttyUSB3 as modem for LTE internet connection and it works perfectly.

For “try logging the bytes (you’d want it to log binary data without any translation of bytes)” How should I do that?
And what would be expected output?

#4

Correct me if I am wrong…it sounds like the USB lanes of the mPCIe are used, and that the Jetson itself sees this as a serial UART. In that case the wiring has to be rather short :P

That might complicate logging. Normally I would log from a different serial program, but is it correct that your hardware requires the old fashioned “AT” commands to initialize? Can you provide more information on what initialization you are told to use prior to any actual commands?

FYI, I see in “man minicom”, under “Filenames and paths”, that option “F” is “Logging options”. I suspect you can create a log file prior to sending the “AT” commands and get even that logged. There might be a need to view that with software other than an ordinary text editor, but we can cross that bridge when we get there. See if you can set a file name for logging prior to any communications.

Also, does your hardware’s documents mention if flow control is needed or not? Flow control (if supported) can make things much more reliable, and if one end thinks flow control is enabled, but the other end thinks flow control is not enabled, then half of the communications may disappear.

#5

Yes USB lanes of the mPCIe is used, these lanes are connected to a USB hub which the path is as short as possible in my design and paralled as they are differential pairs.
I don’t think this is the issue.
I see now a strange thing, when I attach the module to the board, then restart the whole system, this issue exists, but when I unplug the module and keep the TX2 ON, and then plug the module back, everything is okay.
It seems that when I unplug and plug back the module the driver (USB to serial for GSM modems) is unloaded and loaded again and it seems that it solves issue.

I don’t know if it’s module driver or linux USB to serial driver causing this issue, but in any case, in other systems it’s working well.

#6

USB is “hot plug”, and so when an attach event is seen the information about the device is made available for drivers so a driver can take ownership. Having this fail during start, but still work later from hot plug, tends to make me believe that something wasn’t in place during boot. Just as an example, and not specific to this case, an FPGA may need a delay in whatever talks to it so that the FPGA itself can boot. Or a power rail might need to be given time to bring up a device. As a more extreme example, if you need a kernel module in order to mount the file system where the kernel module appears, then boot itself would fail. Timing.

I couldn’t tell you what it is, but something is probably occurring out of order when doing a cold boot. Does a warm boot work if the preceding cold boot failed?

#7

How should I try warm boot? you mean using sudo reboot?
I even tried to use modprobe to unload usbserial driver and load it again but unfortunately the driver is builtin in the kernel and I can not unload it.

I also tried another module based on another manufacturer and still I have the same issue.
I don’t think the issue is for linux system in general, because I have tested with ubuntu on iMX6 and iMX7 ARM embedded processors and also my laptop with ubunut and it works well.
I think there is an issue with linux option or usbserial drivers in TX2 module kernel.

#8

Any other comments?

#9

Starting the hardware from full cold stop is a cold boot. If a running system is given a command to reboot, then it is a warm boot. Example warm boot:

# Start with a normally booted system
sudo shutdown -r now

It would still be of interest to know if the error goes away with a warm boot, versus a cold boot.

If a module cannot be unloaded, then it implies the module is in use. The reference count of users of the module must be zero prior to allowing rmmod.

I think the iMX6 and iMX7 are a different architecture. Correct me if I am wrong, but I believe those are ARMv7 (arm32/arm/armhf), not ARMv8 (aarch64/arm64). Any module working on ARMv7 is not compatible with a TX2. On the other hand, if those modules are from stock kernel source, then there is no reason you cannot rebuild those in ARMv8 architecture.

Someone else may have a better way to debug, but I do suspect there is an issue with needing a delay or enforcing some order of loading during boot. Maybe not, but I don’t know how to determine if that is the case or not (see comment #6).