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.

SN75176B: SN75176B

Part Number: SN75176B
Other Parts Discussed in Thread: THVD1550

I’m using SN75176B Differential Bus Transceiver in one Input module with uC AT89S52-24U. I’m getting errors in differential RS-485 communication. I’ve attached SN75176B signals captured. I observed glitch in Communication signal (RS 485, signal ‘A’, Channel 4), when DE (Channel 3) is low, and before signal D, (channel 2) is going High, because of this condition we’re getting communication errors. This condition occurs on every Power ON state, so whenever module is inserted in system, we get error in communication.

Actually, When DE is low, till that period there should not be any impact on differential Signals ‘A’ and ‘B’.

This scenario occurs when I used AT89S52-24JU uC, but this is not observed with NXP uC P80C32 uC. I’ve attached both scenario. Can you please analyze  this condition and inform us why this is happening?

        

  • Kshitij,

    Can you confirm the waveforms in the second oscilloscope capture? That is, which channel is which signal, I'm curious if this is related to power-up timing.

    Also, if possible, switching to the THVD1550 might be a good idea, it's a newer, more robustly designed version of this device.

    Regards,

    Eric Hackett

  • Hello Eric,

    Thanks for reply,

    Ans to 1st query:

    waveforms in 2nd scope are

    Ch1: None,  Ch2: VCC,   Ch3: TXDIOL (Signal D),  Ch4: Differential signal A

    I want bring one point to your notice that you can observe  in 2nd Scope (uses uC 80C32), Signal D is almost following Vcc, while in Scope 1 (uses uC 89S52-24JU) is delayed 2.5mSec to VCC. Not sure is this valid condition.

    Also I'm wondering at every Power ON it looks like SN75176B is driving RS485 lines, don't know why, as when signal D is low till that time there should not be any impact on differential line. But still we're observing communication error at every Power ON.   

    Ans to 2nd Query:

    As of now we cannot use suggested alternate part as of now because  module is in production currently  and to use alternate we need to qualify extensively. We don't have sufficient time as fulfill the current customer order   

  • Kshitj,

    Yes, I noticed that as well, I'm wondering if there is a small period of time during VCC power up where the bus driving circuits activate before the driver enable circuit, and the driver is able to drive the bus based on the D input for a short period of time. And this may be based on ramp rate as well. It doesn't seem logical, but it seems like the ramp rate and power-up timing are the most obvious differences between the two setups.

    Is it possible in the case where the bus glitch happens to hold the D line high when the VCC is powering up? Or to power up VCC after D has powered up? Also, in the case where the glitch happens, can the B signal be observed on the oscilloscope with the A signal?

    Regards,
  • Eric,

    There is already pullup resistor of 3.83K Ohm on signal D (pin 4). I changed it to 1K ohm to make more strong pullup. Still it is not improving.

    One more modification I did that I added 1K pull down resistor on Driver enable pin (DE, pin 3). I saw some improvement that glitch is now coming randomly instead of every Power ON. After this modification I observed that whenever glitch appeared DE signal rise delayed by 2.5 mS to VCC., otherwise it is following VCC.Just like showed in previous snap of scope 2 (which uses uC 80C32SBAA).

    In 2nd experiment

    I made even more strong pull up of 475 Ohm, so I observed that glitch amplitude is reduced to 800 mV from 1.2V and also time duration is reduced significantly. And also observed that glitch appearance frequncy is also reduced, approx. after 6 -7 times Power ON it is coming. I removed Pulldown resistor to check impact. Actually there is no impact of Pulldown resistor, whether it is there or not.

    I checked other differential signal B i did not observed any glitch there. It is appeared on signal A only      

  • Kshitij,

    Understood, I wanted to know if it was possible to hold D high because VCC even begins to power up, I wanted to see if the state of the D pin was having an affect at power-up.

    Just to clarify again, you mentioned previously that the signals in the 2nd scope shot included VCC, D, and A, but in this post you mention DE signal rise. I'm going to assume that meant D signal rise. And this only happens with the AT89S52-24JU, correct? And when the glitch does happen, is the delay for D to power up always 2.5ms, or different every time? And is there anything driving D at this time from the processor, or is it only going to a logic high through the pull-up on VCC?

    I'm going to test this in the lab to see if I can replicate it. In the fist screenshot you sent over with the glitch happening, you can see D trying to follow VCC and then something pulls it down. It looks like the AT89S52-24JU is pulling the D line down during power up as some kind of reset mode before releasing the pin after a voltage threshold is crossed. It looks like that threshold is ~4V. And during power up, it looks like this transceiver has a small window where the bus driver will drive the D pin state regardless of the state of DE. One thing I'm not sure of is why the glitch width and magnitude change with the stronger pull-up resistor.

    Is there any way you can provide a schematic of the system, or just of the RS485 transceiver and the processor connections? If you don't feel comfortable posting it on E2E, you can find my email by clicking my username and emailing me directly.

    Regards,

  • Kshitij,

    I received parts today and will start testing. Are there any updates from your side, were you able to get anymore information?

    Regards,
  • Eric,
    Thanks for info, I sent separate mail containing part of schematic and explanation.
  • This thread is now being handled offline, and will be closed.