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.

SN65C3222E: SN65C3222EDBR drop in replacement for SN65C3222DBR?

Part Number: SN65C3222E

HI

We used SN65C3222EDBR as a drop in replacement for SN65C3222DBR and unfortunately it is does not work for use.

Measurement show us that the timing of the first bit in data packet is different between the two components.

Our data rate is 0.7Mb/s.

Vcc 3.6V

Pleas advice is SN65C3222EDBR  valise replacement for SN65C3222DBR and what can be done to make it work.

  • Eduard,

    Do you have pictures of the waveforms for both devices? And by timing of the first bit, do you mean the rise/fall time?

    Regards,

    Eric Hackett 

  • In the photos below you can see the input of a driver  (Yellow) and the out put of receiver (Blue).

    you can see that i captured a pulls that is a lot wider then the pulls on the driver side. My application is pulls width sensitive (LED driver), so the wider pulls can be interpreted as wrong data( "1" instead of "0") .

     

  • Hi Eduard,

    I have a few questions aimed to help narrow down the problem area if you could please help to answer these I'd greatly appreciate it! 

    1. How many units have you tested? 

    2. Do you know the loading impedance that the RX pin is connected to? 

    3. Also what is your scope considering "width" in this case ?   - it seems to be starting very low on the signal, but I may just be interpreting the picture incorrectly. 

    The RX timing specs are the same between the two devices (the "E" version should be drop in in most of the applications  including this one is what I'd assume based on the schematic and non-E version was working) 

    There could be some pulse skew that is causing the extension of the signal (its up to 300ns) but knowing if this issue is being repeated and how the load looks would be great - I'd imagine its high impedance but I am more interested in the capacitance of the RX output. Please let me know and I will see what I can do to dig into the problem a bit deeper. 

    Thanks!

    Parker Dodson

  • HI Parker,

    Thanks for your response.

    1. I tested 3 sets and my manufacturer tested a lot of boards. All of them failed to produce the required LED's patterns with E type and pass after replacing to non E type.

    2. We use Molex connector with 22AWG cable to chain few LED boards (~10 in length). The transition is always point to point(one driver to one receiver).

    3. You can see in screenshots that the  Yellow transmitted pulls time is 322ns  (Yellow "+ width" measurement line).  The blue received pulls is  451ns ( Blue"+ width" measurement line).

  • Hi Eduard,

    Thanks for the reply. So based on the results that you are seeing - the part is still operating to the specification listed in the datasheet. The propagation delays can be uneven and can differ by up to 300ns - which means that the output pulse could be stretched longer (and with the extension that you are seeing this is possibly it. 

    Since the part is being pushed closer to its maximum data rate the output capacitance will affect the output quite a bit. If possible can a test be conducted to shorten the bus length to see if that improves the situation or use a possible dummy load (like a 3K ohm resistor) to see if there is an issue with the LED load. Why is the non "E" version working - I am not 100% sure they are spec'd the same - but the non-"E" version , based on datasheet could suffer the same problem . Essentially the part isn't out of spec but the setup may be giving a hard time for the part. 

    Please let me know if these tests are possible to see if the loading is effecting the system because things that could affect the skew is really the output.

    Best,

    Parker Dodson