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.

TCA5405: TCA5405 Problem

Part Number: TCA5405

Hi Team,

I need your support with TI component I am evaluating for my design.

Thanks,

Shlomi

TCA5405.docx

  • Hello Shlomi,

    It will look into this today.  Thanks for the detailed information you sent. 

    -Francis

  • Hello Shlomi,
    I am a bit confused about what you are said and what the waveforms are.

    You state the "purple probe is the required output shape". Is that channel 4? It looks like pink, I assuming that what you mean by purple (channel 4)? What do you mean by output shape? What is the scope probe on physically?

    I assuming channel 2 (green) is not used. Can you remove it from plots. Also, can you separate the waveforms to they are not overlaid on each other. It is difficult to see.

    I see what you are seeing, where the second set of plots don't show Q0 going low. Did you see if maybe the Q1 was going low. Maybe it's a timing issue.

    I am going to get some parts here so I can test this part. I don't have any in house right now.
    -Francis Houde
  • Hi Francis,

    Any update? did you got some parts to test this part?

    Thanks,

    Shlomi

  • Hi Shlomi,

    You mentioned that other IOs behaved the same as Q0 in that they can sometimes take the wrong value. In general, though, do you see Q0 taking the wrong value more frequently than the "earlier" IOs like Q4? If so it may indicate timing issues (e.g., the internal oscillator not matching up with DIN's set-up period exactly). That would be my initial concern given that operation seems to be towards the faster extreme of this device. (Along that similar line of thinking, have you tried drastically reducing the operating speed? It also may help to zoom in much more on each data burst so that the individual bit periods can be measured accurately.)

    Max
  • Hello Shlomi,

    I got the part on a board and got a waveform editor for a function generator to be able to replicate the signals you were sending.   I used 2us pules for the timing and I was not able to get an error like you saw.  I did play with the second pulse duration to see where the device would fail. 

    As you see from the above it worked for changing the period to 2.48uS.  I expanded it until it broke at 2.56us, see below.

    To me this shows me that it broke at about 25% change in period, but that was the second period, though looking at the first period would also be a good exercise.  Can you zoom in on your waveforms and take as accurate measurement of all the periods to make sure we don't have large shifts. 

    I can then reproduce your waveform you record if all the timing information for both the rising and falling edges. 

    -Francis Houde

  • Hi Francis,

    I don’t think that this is a timing issue, I drive my DI signal from a shift register with a constant 500KHz clock.
    I did notice though a bug on my system that I could not yet solve, it inserts false single bit low signal randomly.
    In this case, since there is no preamble to synchronize with, I would expect the TCA5405 to ignore, but it doesn’t, it just fails on the next good command.
    I suggest testing that by deliberately inserting short low event to DI randomly between writing, and check if the device operated properly on the following command.

    Thanks,
    Shlomi
  • Hello Shlomi,
    Can you get the entire transaction of DIN and IO failure from your scope in .csv so I can import into excel and look at timing and try to reproduce the signal using my waveform generator. If you have a setup that repeatedly is able to see the failure then we should go with that. Otherwise I will have to try a large superset of variable changes just to see it. If I can get the exact conditions that cause this I can see if I can reproduce it. If I can reproduce it in silicon then I can show our designers what is happening and see if they can figure out why it is happening and what to do to avoid this problem.
    -Francis Houde
  • Hi Shlomi,

    I just wanted to check in - what is the status of this issue? It seems our testing here required a fairly large timing violation before bit errors occurred, so I think it would be interesting to try Francis's suggestion to allow us to recreate the timing in your application more exactly to see if there is perhaps some subtle effect that we missed.

    We may also have difficulty recreating the issue if it is not observed in all (or at least most) units. Have you tested several parts? If so, are all of them showing the same behavior?

    Regards,
    Max