EHS5 module ASC1 trouble | Telit Cinterion IoT Developer Community
December 7, 2016 - 8:40am, 5960 views
Hi all!
I use EHS5 module. It is soldered into my board. All works perfectly but I got trouble with ASC1 port.
I use it as RS485 interface with SN65HDV01 chip. It was no connection and after complete checking of the board my colleague found that TXD1 and RXD1 on the chip are swapped. Really! When I wrote to the port from JAVA-midlet there was no output signal on TXD1 29 pin (directly on EHS5) but I saw this signal on RXD1 30 pin. So I swapped these pins and now my modbus package is successfully reached for my device ( I use external terminal to spy). But anyway there is no response from my device.
Also I'd like to ask how to be with RTS and CTS. CTS of EHS5 is connected to DE pin of RS-485 chip. RTS of EHS5 is on the ground. When I create the connection I use "autocts=off autorts=on". If I change autocts to "on" there is no output packet from RS-485. Changing the autorts to "on" or "off" makes no influence on the transmission.
So the question is... Is Gemalto really swapped 29 and 30 pins? How to adjust the port for RS-485 transmission?
I hope for some help to understand my problem. Thanks.
Hello,
The ASC1 lines are shared with GPIO liens and this is configurable with AT^SCFG command.
The RX and TX lines are not swapped. According to the hardware interface description EHS5 is designed for use as a DCE. Based on the conventions for DCE-DTE connections it communicates with the customer application (DTE) using the following signals:
• Port TXD @ application sends data to module’s TXD1 signal line
• Port RXD @ application receives data from the module’s RXD1 signal line
The ASC0 supports RTS1/CTS1 hardware flow control. Communication is possible by using only RXD and TXD lines, if RTS1 is pulled low.
Generally it is recommended to use the HW flow control and it was the only option in the older releases. In release 3 there are also other settings for flow control (see AT\Q command, for Java MIDlet you configure it with autocts and autorts in Java).
I will also send you some reference design document - maybe it will be helpful.
Regards,
Bartłomiej
Thank you for reply.
Configuration of port is proper.
^SCFG: "GPIO/mode/ASC1": std
Port is visible in system and available for opening.
I'll try to check again.
Ok. My cfg
^SCFG: "Serial/Interface/Allocation","1","1"
^SPOW: 1,0,0
at&v
ACTIVE PROFILE:
E1 Q0 V1 X4 &C1 &D2 &S0 \Q3
So Q3 - hadrware flow control is enabled
commConn = (CommConnection)Connector.open("comm:COM1;baudrate=57600;autocts=off;autorts=on;blocking=on"); outStream = commConn.openOutputStream(); byte[] arr2 = new byte[8]; .... fill arr2 with modbus packet...... outStream.write(arr2); outStream.flush();Well now is very important fact!
I send this packet like in above code.
I measure by oscilloscope on the TXD1 pin of EHS5. And I see nothing. But output signal must be there.
But I see this sent signal on RXD1 ping of EHS5. It is unbelieveable but it is fact. RXD1 pin is designed to receive data. Not to send!
Ok. We swapped these pins and my RS-485 works properly. Thesend modbus packet is reached the application device.
What's going on with EHS5? I am sure these pins are swapped.
BTW. If I use autocts="on" in commConnection there is no output signal produced.
P.S. Your reference scheme is used only RS232. Do you have any examples with RS485?
My current scheme for RS-485 connection.
EHS-5 sends the Modbus RTU request to my device.
EHS-5 receives the response from my device on each request.
Hello,
Regarding the swapped lines please see the picture for the information I have sent you before about DCE (module) and DTE (PC or other device) connection:
Regards,
Bartłomiej
By oscilloscoping...
If I open port with "autocts=on" I see asynchronous sending my packet and impulse on CTS1.
It means that creation of CTS1 signal is asynchronous with data sending through RXD1. And packet is not passed.
If I open port with "autocts=off" I see the high level on CTS1 during the whole process of port opening. And the packet is passed succefully and it is reached my device. But when my device is answered the response packet is dropped because CTS1 pin is on and 485-interface chip is busy with modem.
So I still can't understand what to do with this trouble.
P.S. Now RXD1 and TXD1 were connected properly. RSD1 is output.
Hello,
The CTS line is used by the module to indicate that it can receive data. If no hardware flow control is set it goes high. So if you disable flow control but still the connected hardware is using flow control and is waiting for the low CTS state it will never send the data to the module.
If your connected hardware does not receive the data if the CTS is low then I think that it is not correctly connected because this line only signals that the module can read.
Regards,
Bartłomiej
Hello,
How I wrote before I use EHS5 with chip SN65HVD that provides RS485 interface. Now the problem is in communicating between this chip and EHS5. This chip ***** to be controlled by CTS to switch the modes between "read/write". In EHS5's datasheet we can see that CTS1 is output pin (Table 2). To use RS485 we must provide the hardware flow control. So it means that EHS5's CTS1 pin has to switch between low and high state to indicate for chip SN65HVD is now to send or to receive. Now it s clearly that ASC1 port works improperly because CTS1 is not switched accordingly to the standard of RS485 interface. In this case I have to use any available GPIO to switch the transmission mode manually for my RS485 chip.
Summarizing...
Now I use GPIO20 connected to the DE/RE of the chip SN65HVD.
Before writing to the port I set the high for GPIO and after it I set it to the low. And read data from port.
In this case I have working code. All Modbus packets is written and read properly.
When I use native hardware flow control, CTS1 behaves itself like madman )
So I wouldn't recommend to use ASC1 for RS485 operations. It's just not operated.
Hello,
Thank you for the summary.
The RS485 and RS232 standards are different and maybe that's the source of the problem. In RS485 only one device may send data at the same time while in RS232 there may be full duplex.
So I would not agree that ASC1 port works improperly because CTS1 is not switched accordingly to the standard of RS485 interface. ASC1 port works according to the RS232 standard where there are separate lines for flow control for each direction and CTS1 line only cares for the buffer for incoming data and is not responsible for switching between sending and receiving, while RTS is controlled by the other party.
I don't know the exact functions of DE/RE lines of your chip. Good that you have found the solution with GPIO. I can see a little risk - software switching might not be as fast as hardware switching. Please test it thoroughly if it's working reliable in all situations.
Regards,
Bartłomiej
Pages