SN75176A: High fallout "bug"?

Hi Jeff,

Could you please show us a schematic of your usage of this device?  I'm mostly curious what is on the RS-485 signal lines as well as the R output pin.

Could you please show us waveform captures showing the behavior you describe?  This isn't an issue I've heard of so I'd like to make sure we understand it.  Most of the time the "R" output would be high after toggling into receive mode since the last bit transmitted is typically a high-level "stop" bit - is this not the case in your application?  And, is the expected idle state of the bus a logic low or high state?  Is there any biasing circuitry that sets a differential offset voltage on the bus when all the drivers are disabled, or does the differential voltage drop to ~0 V in this case?

Regards,
Max

Hello Max,

Thanks for the reply.  I did a more in-depth log with a logic analyzer, and now I understand what is happening, but don't think the behavior of the device is proper.

I have attached two jpegs, one of the schematic snippet of the 485 transceiver, the other the logic waveforms.  The circuit is really simple, RO and DI are connected to optoisolators to feed our controller.  We have nothing on the bus A and B lines, so my board tester simply has another one of our boards to act as a slave.  Our board is basically a smart protocol converter, so we ping between the DUT and the slave board for all the various protocols.

At idle, we rely on a HI state for the 485 line, and since all of our protocols except CAN are bit-banged, to read bytes we rely on interrupts, so for the 485 we look for a falling edge.

See the attached waveforms.  Line 2 (RED) is where the device under test sends out a byte of data (0xA6).  Since this is a closed system, instead of using my mixed analog and digital analyzer, I simply used the digital log on the actual bus lines.  (wont show the actual voltages, but know whether the voltage on the bus is above logic level or not)

You can see that the proper signal is on the BUS A and B, then Line 3 (Orange) shows the byte of data at the RO pin of the Slave board.

Everything so far is OK!

However, shortly after sending out the byte, I toggle the RE\ DE lines low (Line 0, White trace) , to switch the Master device from transmit mode to receive mode.  At this point, both the Master and the Slave devices are in Receive mode, so the bus is effectively floating.  I don't know the exact voltages present on the bus A and B, but you can see that somehow the BUS B line is getting pulled high, consequently the Master RO line is getting pulled Low.  

My current slave software enables the Drive line right before the slave starts transmitting the response byte.  However, it is too late to catch the start bit of the byte, so my interrupt on the Master doesn't see the start bit.  

I was able to easily "fix" the tester by simply changing the slave software to toggle the RE\ DE line high immediately after it reads the byte from the master. 

HOWEVER, in our application, we don't talk to another one of our boards, we talk to a number of other single-ended controllers where I have no idea what idle state their 485 controller is on the bus.  It might be biased high, but might not be.  Furthermore, I believe the device as shown is not matching the specs on the TI datasheet.  The datasheet logic chart shows that with open bus and RE\ DE pulled low, then RO should be High.  That is not what is happening here.  So although I can "fix" my tester to pass these devices, but I don't know if I am risking field problems by putting these out in the field.  (All the units exhibiting this behavior haven't made it out to the field; we have been swapping out the 485 transceivers when this happens on the test stand)

Your thoughts are appreciated.

Jeff

Had to open another reply to attach the waveforms

Had to open another reply to attach the waveforms