1

I just received three USB TTL adapters each with a different chipset, and was testing them. The CP2102 (I already own one, and it works normally) shows a weird defect: either by connecting it to another adapter (either of the two) or working in loopback, it will not TX data. No led activity, no bytes received on the other side (when it's connected with another adapter). By chance though I noticed that when I close minicom (Ctrl-A, X, Yes), all that wasn't sent before, gets send at the same time after minicom closed (at least certain amount of data, I tried sending a file in ASCII mode and only a handful of rows of it was transmitted to the other adapter when I closed minicom).

OS is Ubuntu 19.04 64bit, and I'm running minicom as root from a terminal window. Either leaving out the baudrate (defaults to 115200) or setting it explicitly to 9600, the same thing happens.

Is this adapter toasted, and it's good just for RX-only appliations, or is there a way to get it back together?

ephestione
  • 43
  • 9
  • It will be difficult to answer the prose questions. Please try adding information, such as the minimum source code to reproduce the problem, the signal line connection specifications between both ports, and the OS being used. – kunif Sep 20 '19 at 23:10
  • @kunif I added more details, but there's not much to it... I specified the OS, the application is minicom, and there is nothing else you can do in that tool apart from typing in the console, or using the menu "Ctrl-A, S" to send a file. Either one of the two leads to no output from the module except when I close minicom. – ephestione Sep 22 '19 at 10:41
  • It is likely that RTS/CTS is not connected but flow control is specified, or device file or library buffering is enabled and actual transmission has not started(for example, waiting for a carriage return), something Is there an error that has stopped waiting to be processed? – kunif Sep 22 '19 at 10:57
  • @kunif your last comment mostly flew over my head, but in my layman understanding I did think that "it's just like I didn't press Enter". It must be something relevant to the adapter itself, as my other USB-TTL modules (another CP2102 and other chipsets as well) "just work". This one instead doesn't. Well I should just write it off as a "hardcoded" flaw and get on with my life, or use it for "RX only" applications. – ephestione Sep 22 '19 at 16:50

2 Answers2

1

You should try to disable Hardware Flow Control in minicom settings:

$ minicom -s

Then go to

Serial port setup

and set

Hardware Flow Control

to No

Ildar Sadykov
  • 11
  • 1
0

In the end, the adapter was not "defective", it just doesn't play nice with the minicom application in particular. I fetched the other "working" CP2102 adapter that I had bought few years ago, to be used for another project from where I switched out a CH340G, and I could use it as expected both in TX and RX with a PHP script that I wrote for a SIM800L. Then I connected to it with minicom because I needed to issue some commands manually, and the same thing that I describe in the question above also happened with this other CP2102. I made a few modifications to my PHP script to make it act as a normal, user operated serial console, and I could both send commands and receive responses succesfully, where minicom couldn't. I then fetched the "supposedly broken" CP2102 adapter, and I also could use it correctly with my homemade PHP serial console, whereas minicom simply didn't accept any user input.

ephestione
  • 43
  • 9