0
\$\begingroup\$

We have two devices connected via a cable, an ARM based computer on one side and a sensor on the other. This cable carries an RS232 TX, RX, and ground. In addition there is 28V provided from the sensor to the ARM computer. When the sensor is powered on, it provides the power to the ARM platform so both systems power up at the same time.

It was observed that in this configuration the sensor refuses to communicate with the processor. If the processor is powered on a seconds after the sensor, then communication works as normal.

An o-scope trace showed that when the processor was powered on, the RS232 TX goes from undefined to 0 and then immediately pulses to 1 and then back to 0. My guess is that if this pulse occurs during the sensors boot, this will cause the sensor to ignore any future IO.

The simple solution would be to disable the TX line for a few seconds while both systems boot. What is the simplest circuit that could be used to perform this? This circuit would need to be built into the cable.

I have seen a lot of delay on and off circuits on this site but most of them look to be switching power, I am not sure if it would be different if it was an IO line.

\$\endgroup\$
  • \$\begingroup\$ What does the data sheet say about the sensor? Have you tried proving this by disconnecting the lead until it has stopped pulsing? \$\endgroup\$ – Andy aka May 5 '16 at 11:38
  • \$\begingroup\$ Check your sensor's communications protocol to see if there is a character or series of characters to get it ready to receive the next data sequence. \$\endgroup\$ – Tut May 5 '16 at 11:39
  • \$\begingroup\$ Specs: arm computer? sensor? "In addition there is 28v provided from the sensor to the arm computer" ??? \$\endgroup\$ – Marko Buršič May 5 '16 at 12:12
  • 1
    \$\begingroup\$ Why do you "have to guess"? Unless you actually perform the experiment, your hypothesis seems doubtful. It seems much more likely that the (unidentified) "ARM computer" is unresponsive during it's (undisclosed) boot sequence period. \$\endgroup\$ – Richard Crowley May 5 '16 at 12:26
  • 1
    \$\begingroup\$ Think about it. We can't know which direction is "TX" and "RX". Which device are these names relative to? It's not clear who is blipping the line at startup. I really shouldn't have to ask this. \$\endgroup\$ – Olin Lathrop May 5 '16 at 12:49
2
\$\begingroup\$

It sounds like you have glitches on the serial signals on power up. This is not unusual and should be expected.

Instead of trying to delay the power coming up to the processor, its firmware should do the appropriate delays and assume the other device is in some arbitrary part of its communication protocol. This should be normal procedure for a embedded system that communicates to remote devices over serial.

Usually the embedded system starts up its UART, waits a few 100 ms, and drains and discards all received characters. Then it sends a sequence to put the remote device into a known state regardless of what state it might currently be in. This might be sending a string of NULLs longer than the longest command, sending a few CR/LF in sequence, waiting some fixed time, etc. The details are highly dependent on the byte-level and higher communication protocol.

In any case, this is a firmware problem. Don't try to fix it with a hardware kludge.

\$\endgroup\$
0
\$\begingroup\$

The physical layer of an RS232 signal uses a voltage swing which is incompatible with common logic level voltages used in computers and embedded processors. This could be the cause of unexpected behavior.

The protocol layer of an RS232 signal leaves much to be desired. Not to mention little used features that may be interfering with your communications which may or may not have been implemented in the devices you are using.

Before resorting to a hardware solution I would try to send an RS232 break signal from the processor to the sensor.

If you are using the real RS232 physical layer it is difficult to switch with logic because the voltage swing is larger then normal logic power levels. You may look into relays, solid state relays or bilateral switches.

If you are using logic level RS232 signals... Well, you are using someone's (FREESCALE.COM, NXP.COM, TI.COM, ect) ARM processor. Such chips are usually very configurable. Simply designate the RS232 TX pin as a GPIO input until you are ready to send real data.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.