This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

ISO1452: Driver enable/Receiver Enable Both Enabled for Half Duplex

Part Number: ISO1452

I am using the ISO1452BDW in a 2-wire, half-duplex configuration. It appears from several other posts on the TI support forums that this should be achievable by tying the Y/A pins and Z/B pins together.

 

Should it be possible to hard tie the ~RE pin to ground, and let another device toggle the DE line upon transmit? In my troubleshooting, it appears that I only see traffic come in on the single-ended R line when ~RE and DE are both tied low. I had thought that it would be possible to leave the ~RE pin low while the DE pin is high, and this would just result in a sort of loopback to allow the data being transmitted out to be received/confirmed. The behavior of the chip would seem to indicate otherwise, however.

 

My question is, should this theoretically be possible? Or put more simply, can I have ~RE tied low and DE tied high and successfully send/receive data?

  • Hi,

    Thanks for reaching out and for your interest in ISO1452.

    My question is, should this theoretically be possible? Or put more simply, can I have ~RE tied low and DE tied high and successfully send/receive data?

    Yes, this is possible and I expect it to work without any issues. RE\ can be hardwired LOW while DE can be made HIGH during transmission and should be disabled while receiving data from the bus.
    When RE\ is LOW and DE is high, you will see D data looped back to R with some propagation delay within datasheet specifications. We test this very regularly and we do not see any problems.

    The behavior of the chip would seem to indicate otherwise, however.

    Could you please share more details on what happens when you try to make DE HIGH and RE\ LOW?
    Please also share schematic and waveform to review and to see if there are any issues in the design. Thanks.


    Regards,
    Koteshwar Rao

  • See below for a schematic snip. The RS_485_+/- lines are switched to the ISO1452 upstream from an analog multiplexer (ADG1409), but it appears to be working properly.

    Here is DE high, /RE low:

    Here is DE low, /RE low:

  • After some further testing/investigation, I think the issue is how we are executing the test. On the single-ended side, we are essentially looped back, so I think the issue is that driver enable is HIGH while data is coming in on the differential side, and then that data is immediately being driven back out on the differential transmit lines, which is causing a contention.

    Based on this, it appears that we may need to leave driver enable LOW while data is coming in, then drive it HIGH when ready to transmit. Does this appear to be correct and align with what is expected behavior for the part?

  • Hi,

    Thanks for further update and for sharing details related to how you are testing the device.

    Based on this, it appears that we may need to leave driver enable LOW while data is coming in, then drive it HIGH when ready to transmit. Does this appear to be correct and align with what is expected behavior for the part?

    Yes, your understanding about making the DE pin LOW to be able to receive data from other nodes on the RS-485 bus is accurate. If DE is held HIGH, then the bus is being driven by the device itself and if any other node tries to send any data, there will be contention and you might not read any data from other nodes. I briefly mentioned in my earlier post (referred below for quick reference) that DE should be made LOW to be able to receive any data from the bus, probably I should have stressed on this point.

    DE can be made HIGH during transmission and should be disabled while receiving data from the bus.

    Your observations are as per our expectations, hence, you can continue with your testing. I will go ahead and mark this thread closed. Let us know if you have any further questions, thanks.


    Regards,
    Koteshwar Rao