I have a serial device with which I am trying to communicate. This device knows when a complete command has been sent when the command string is terminated with a "\r". Thus, a typical command string might be something like "COMMAND \r".
I'm having trouble configuring stty in such a way that the carriage return gets sent to the device. Currently, the device will not respond to any of my commands, so it's as if the input to the device is still "hanging."
I've written some simple C code where I bypass the terminal and there I can successfully elicit replies from the device, which is the reason why I think that the commands are not being properly terminated in the terminal. I've tried many different permutations of -+onlcr, +icanon, etc to no avail. The baudrate, parity, data bits, start and stop bits are all properly configured, as far as I can tell.
How can I debug this issue?
What is the platform (machine)? What is the OS?
Have you tried to flush the output with
fflush( FILE * FP );
Tried COMMAND\r\n ? What's the device?
Related
I am trying to control 5V 4-Ch Relay Module http://www.icstation.com/icstation-micro-channel-relay-module-control-relay-module-icse012a-p-4012.html using Raspberry Pi-4, Model-B, 2GB RAM.
But sometimes I am observing "pl2303 ttyUSB0: pl2303_read_int_callback - usb_submit_urb failed with result -1" error and the Relay did not perform the required operation.
It would be good to know the root cause or the reason for this issue from the professional present here on this forum.
Any hint/clue would be really helpful and appreciated :) .
Thanks Again.
TL;DR: there seem to be a defect in pl2303 driver caused by race or incorrect state after multiple connect/disconnect. Simply reload the pl2303 kernel model to workaround this issue when you get it.
Error '-1' (EPERM) in kernel USB stack is rare: I can find only one occurrence in urb submit path e.g.:
https://elixir.bootlin.com/linux/v5.4.99/source/drivers/usb/core/hcd.c#L1152
More to this, kernel documentation on usb_kill_urb says:
To cancel an URB synchronously, call usb_kill_urb():
void usb_kill_urb(struct urb *urb)
It does everything usb_unlink_urb() does, and in addition it waits until after
the URB has been returned and the completion handler has finished. It also marks
the URB as temporarily unusable, so that if the completion handler or anyone
else tries to resubmit it they will get a -EPERM error
So basically driver tries to submit INT IN URB after it got killed. Looking at the pl2303 driver code you can see only 2 places where INT IN URB is poisoned, e.g.:
https://elixir.bootlin.com/linux/v5.4.65/source/drivers/usb/serial/pl2303.c#L756
https://elixir.bootlin.com/linux/v5.4.65/source/drivers/usb/serial/pl2303.c#L788
In both cases this happen on either close() or unsuccessful open() of USB serial device.
Proper fix would be to:
Check whether its open that fails on usb_serial_generic_open() function
Check whether INT IN URB killing is done properly and there's no race
Check if pl2303 code is aligned in general with recent USB Serial driver logic
Quick fix on the running system would be just
rmmod pl2303 && modprobe pl2303
I send USSD command with AT.
Sometimes I receive the response CUSD=4 sometimes it works for the same input.
The error always appends at the beginning of a new USSD session (#xxx#).
Do you know what exactly means this response? The description of the error is operation not supported.
Is-this message due to the modem or to the network?
How can I avoid it?
Such message mean you(or soft) issues AT+CUSD command
Any response except 0,1 are errors.
Exact error have follow message. Try enable debug to see full message.
Code 4 can mean different things depend of modem used, for more info you need check AT commands for modem you have.
I am communicating with a server from Verifone Nurit8320(DTE) via siemens MC55 gsm modem(DCE).
I am passing AT commands via UART to give commands to siemens MC55 gsm modem (DCE).
I have given a delay of 100 ms (required) between every AT command and I am flushing the UART of DTE before sending any command on it.
Now the problem is this
In many cases DCE is responding with the response of the previously executed AT command. The DCE UART is never flushed.
Where can I get the set of AT commands so that I can flush the UART buffer of DCE?
The problem you are trying to solve (flushing the DCE UART) is the wrong problem to focus on, because it is a problem that does not exist in AT command communication.
After sending an AT command to the DCE you MUST read every single character sent back as response from the DCE, and parse the text until you have received a Final Result Code (e.g. OK, ERROR and a few more) before you can send the next AT command. Any other way is doomed to bring in an endless list of problems and will never, never, ever work reliably.
See this answer for a general outline of how your AT command sending/parsing should
look like. Using a fixed time delay should never be done; it will either abort the command or in best case waste time while waiting unnecessarily long while never removing the risk of aborting despite of waiting. See this answer for more information about abortion of AT commands.
I'm working on the firmware of a device that is going to be connected to PCs using Bluetooth in serial port emulation mode.
During testing, I found out that modem-manager on Linux "helpfully" tries to detect it as a modem, sending the AT+GCAP command; to this, currently my device replies with something like INVALIDCMD AT+GCAP. That is the correct response for my protocol, but obviously isn't an AT reply, so modem-manager isn't satisfied and tries again with AT+GCAP and other modem-related stuff.
Now, I found some workarounds for modem-manager (see here and thus here, in particular the udev rule method), but:
they are not extremely robust (I have to make a custom udev rule that may break if we change the Bluetooth module);
I fear that not only modem-manager, but similar software/OS features (e.g. on Windows or OS X) may give me similar annoyances.
Also, having full control over the firmware, I can add a special case for AT+GCAP and similar stuff; so, coming to my question:
Is there a standard/safe reply to AT+GCAP and other similar modem-probing queries to tell "I'm not a modem, go away and leave me alone?"
(making an answer out of the comments)
In order to indicate I do not understand any AT commands at all (aka I am not a modem) the correct response to any received AT commands should be silence.
In order to indicate I do not understand this particular AT command the correct response should be ERROR.
Anything between will trigger implementation defined behaviour of the entity sending AT commands. Some will possibly give up right away while modem-manager apparently is set on retrying sending the command until it gets a "proper" response.
I have an app that is connected to the balance through the serial port. The balance is quite large and pressing the PRINT button is not an option. So my app asks the balance to print programmatically upon a certain user action. The balance interface allows it, and defines a print command. All works for awhile. Then after weighting few items, the balance starts outputing the previous weight....I am buffled at this point since there are few commands defined and there is not too many options to what can be done. I am already flushing out the OUT buffer after each time. So I don't know why it keeps giving me the old value.
Here is my code:
if (askedToPrint)
{
_sp.DiscardOutBuffer();
//ask the balance to print
_sp.Write("P\r\n");
}
_sp - is a SerialPort object
I am using WinCE 6.0 and Compact Framework 2.0/C#
if you are reading data from serial port using Readline() or Read() then there is a possibility that balance have sent multiple packets queued. So before reading you have to discard already pending packets. other way around is before writing request to print use ReadExisting() method to read all available data. So after sending command if your balance still sending old packets then there might be a problem with balance.