I'm having an issue connecting a serial device to an embedded device I'm writing code for.
The device I am writing has two serial ports, an incoming from my laptop, and an outgoing to an external device.
When I connect both terminals to my laptop and view the data, I get exactly the data I am expecting.
When I connect my laptop to the external device directly, I am getting exactly what I expect, and a response.
When I connect the laptop and the external device to the embedded device I am working on, the laptop sends data to it, it receives it, it passes it on to the external device. This works as expected.
However, the external device doesn't send back the response.
If I send data to the external device from the embedded device, each new message I send allows it to send the original reply.
I know the first message got through correctly because the external device whirrs to live, and I know when it is sending the response by running and logic analyser on the tx/rx comms and viewing the traffic.
I considered that the embedded device is holding the rx line and preventing its transmission, but I don't see how that possible in the code. Also if that is the case it shouldn't work when I plug both lines into my laptop.
I also considered the DTR was not set high, but checked this and it appears to be set high.
Does anyone know a reason which would prevent a device from responding?
Note: When I say Serial Ports I am referring to the UART when referring to the embedded device. All device use a DB9 connector running RS232.
Edit: Operating System on laptop is Windows 10. Embedded device is a Atmega324p.
Edit 2: Did some more testing. It appears that it sometimes work and sometimes doesn't.
I have added an image which show a almost perfect signal of the response.
The blue section is a gap in the signal that shouldn't be there.
Ended up finding a solution.
The RTS line was held via the embedded device at 1.2v, while the Pc was holding it at 5.2v.
Pulling the RTS line up to 5v fixed the issue.
Related
I'm working on Linux system that using modbus rtu RS485 to send and receive data. My device is master and just send "request latest data"(8Bytes include 2Byte CRC) to slaver (from now is only 1 slaver) every 1second. when Slaver receive request, they will prepare data (71Bytes include CRC) and send back to Master. I can't see the source of Slaver because this is commercial product.
Both of Master and Slaver using same baud rate 38400.
Result:
When check communication between Master and Slaver, sometimes (average is 1-2hours) data from Slaver is lost some first Bytes, and first Byte that received has been modified with other value that sent from Slaver (sometime lost some first Bytes only)
Sometime data from Slaver not come (timeout but do not receive any data). I tried to increase timeout by 500ms or 1sec but still occurs without any change
I tested Slaver by communication with Teraterm and there is no error like above. Data that sent and received are OK. With Master, I also tested with Teraterm and there is no error.
When I try to catching data while Master and Slaver send & receive data, when problem are occurred(not receive any data or lost some first bytes) on both of Master side and on my PC side (try to catching data byte Teraterm on PC).
I believe that problem is on Master side, and maybe on serial port setting, but I don't know where were wrong. Please help.
Sorry for my poor English!
I used to work with RS485 bus a lot. And one problem that sometimes appeared was very similar to your. Because RS485 is half duplex bus, there is mechanism that switching receive mode and transmit mode on RS485 bus driver. And this was exactly cause of my problems.
When master device sent some data, slave was ready to reply (and replied) before bus driver (on master side) was switched to receive mode. This behavior ended with data loss.
May I suggest you to check, using oscilloscope, that slave sent data correctly? If so, you probably don't have too much options to do as possible solutions are:
Slave have to wait some time before sending reply to master.
Change HW, some RS485 driver that will be faster in switching modes or use different BUS.
I'm trying to send and receive data between a board (Dialog DA14531) and a simulation application of a temperature sensor.
I can easily send and receive data between the board and my computer, using Termite for instance.
By using Com0Com, I can receive the data sent from the sensor simulator in Termite as well.
However; I can't directly send data between this simulator and my board. I'm using Advanced Serial Port Monitor application and while the simulator states that the connection has been established, there seem to be nothing going on with this port.
Does someone have any idea about what might have caused the problem and how should I proceed for debugging?
So, I've figured out a new way to fix the issue:
Created a pair of virtual ports by using Com0COM.
Connected the simulator to one of these ports and Termite to the other one.
Connected the board to the system.
Used port forwarding in Termite to send the received data to the board.
This way, I can also monitor the data traffic between the board and the simulator.
I just need what I hope is a little help re-directing the text coming into COM5 to be sent out on COM3.
I have an android phone which sends GPS NMEA data to my laptop. This shows up on COM5 in Device Manager.
I have a serial device (computerized astronomy telescope mount) which needs the NMEA data stream at power up. This is attached through a USB to Serial dongle showing up on COM3.
Both connections are working.
The only thing I need is a way of passing the incoming GPS data to the mount through its COM port.
I wonder why you need to put a PC in the middle to forward the NMEA commands and not connect both serial devices directly.
I guess you have your reasons; whatever those are you can do that very easily with Termite:
https://stackoverflow.com/a/56377015/11476836
I'm using stm32l151 and I want to use usb peripheral in cdc mode. I used stm32 cubeMx to generate the project. however the function CDC_Transmit_FS() always return USBD_BUSY. can anyone help me?
Here is my code:
while (1)
{
CDC_Transmit_FS(Buffer, 6);
HAL_Delay(2000);
}
I only added the above code to the project created by STM32cubeMX but it didn't work.
STM library is buggy and it stalls when you for example try to send many larger packets of data.
There is a problem with the windows drivers and there are quite long delays between packets. So 12MB is quite difficult to archive - using CubeMx I could only have about 3-4Mb (12MB when packet is sent).
Another problem I had - I needed to send some data to the device bofore I could transmit next packet (max 8kB in my case), otherwise it stalled randomly.
Fortunately, the problem is solved and I can receive data in the PC from the STM32. There was a problem in my terminal software. I used serial port manitor to monitor the received data from the serial port, however this serial monitor software do not open the serial port by itself and if any other software opens the serial port and receives the data, it monitors data receptions. I didn't know that.
Thanks
this might be a stupid question,
I was debugging a USB storage device on an ARM-CortexM4 platform (STM32F4 series) which runs embedded Linux. The ARM is working as USB host, and tries to communicate with a thumb drive in USB full speed (12Mb/s).
Now here is the problem. After successful enumeration and several SCSI commands thru BULK transfers, the capacity and everything can be read correctly. However, after about 15 seconds when I try to send these SCSI commands again (under same condition), the USB host controller just returns 'Transaction Error', which looks like the device is not responding to BULK transfers anymore (not ACKing) and the host controller times out. The question is, is there any timeout mechanism for USB mass-storage class or SCSI system such that, after a timeout the system must be re-enumerated or re-probed, otherwise it won't respond anymore?
I understand this might be due to a stupid error in my program, or due to some limitations on the specific hardware. However when I used usbmon module in Linux on a PC to capture the transfers on the very same thumb drive, I can see the operating system actually sends a sequence probing command (Read-max-Lun followed by Test-unit-ready) every 5 sec, which could be the reason why the thumb drive doesn't fail on my PC.
Thanks! I'm looking forward to any replies.
I think you're on the right track with the Test Unit Ready commands.. I am in the middle of writing a mass storage device driver for an embedded device and When testing on OS X, after the initial SCSI queries, my device receives Test Unit Ready command about once every second when no other activity is occurring. Since your post is quite old, I recommend you post your own solution if you've since solved your problem.
Otherwise try adding periodic test unit ready commands from the host side when there is no other activity.. You could set and activate a timer whenever USB activity is occurring. If the timer fires, u can send a Test unit ready command.. Rinse repeat.