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.

DDC232: Read-back pattern

Part Number: DDC232

Hello!
I have been testing the DDC232 board with a short molex cable (~10cm), a long molex cable (~50cm) and a usb C. Everything else remains the same, but when switching the cables to acquire data I have came across some issues with the read-back pattern. With the short molex cable everything works as expected, as I obtain the configuration register, the test pattern, some zeros and then these values are repeated. However, when I use the long molex the configuration register is wrong, as well as the test pattern and the repetition is not true because two of the characters changed (from 0 to 8 in both cases). Finally, on the usb C the test pattern is also different to the expected, the repetition is not true and the configuration refgister is only correct the first time. I copy below the read-back information I receive in each scenario in case anyone can help me find out what is happening.

Short Molex:

1801000000000000000000000000000000000000000000000000000000000030F066012480F69055

1801000000000000000000000000000000000000000000000000000000000030F066012480F69055

Long Molex:

0C0080000000000000000000000000000000000000000000000000000000001878330092407B482A

8C0080000000000000000000000000000000000000000000000000000000001878330092407B482A

Usb-C:

1801000000000000000000000000000000000000000000000000000000000030706601A400F61055

9801000000000000000000000000000000000000000000000000000000000030F06601A480F69055

Thanks in advance,

Sonia

  • Hi Sonia,

    Sorry but not sure I understand your question... You talk about a cable, but where is that cable? I can see that it may be between the DDC232 and your controller (?) and I can picture the Molex one (probably a ribbon type, with the SPI signals, supply, etc...)? How about the USB one? Doesn't look like something you can use to run the same signals...

    Regards,
    Edu

  • Hi Edu,

    Thank you for your answer. Let me add some more details: we use the DDC board coupled with photodiodes for the input, and then the output of the DDC232 is connected to an FPGA via an FMC board. The cable I am talking about is for the output, between the DDC232 and the FMC board. We know that everything works when using the short molex (and you are right, it is a flat flex ribbon cable) but if we use a longer vesion of this same cable or an usb-C the read-back pattern is messed. I tried to make sense of the read-back patterns received but can't...

    Thanks,

    Sonia

  • Looks like whatever is driving the cable may not be strong enough? For instance, is the output of the DDC232 to the cable buffered? Have you checked with a probe on the signals (in either direction) to see they look ok?

    And just curious, how do you get a USB-C to replace a flat ribbon cable? Those are two very different type of cables...

  • Hi Edu,

    Just to clarify, we have designed our own circuit boards to collect the output from 32 Hamamatsu photodiodes and digitise them with a DDC232. On that board there are 2 connectors — Molex and USB-C — that we can choose to use depending on the connection options with our FPGA. We also have a custom FMC daughterboard with both Molex and USB-C connections. The cable connections I am describing are between the FMC daughterboard and the DDC232 photodiode circuit board. The two connection types provide identical signal connections (with judicious use of transmit/receive pins on the USB-C cable) but only one is used at once.

    The first thing to understand is what the test pattern means and why differences might be occurring. In answer to your question, when we look at the individual signals we don't see any obvious issues: clean square pulses timed with the system clock.

    Thanks again!

    Sonia

  • Quickly looking at the pattern, it looks to me like your data is getting shifted (delayed) by one clock when you read it. Check again with the oscilloscope. One signal vs the other. It may be that the output of the DDC needs a driver (too loaded by the cables) or that there are some mismatch in length. 

    In any case, the test pattern is just that, a test pattern. Not an error code. It just helps you debug by looking at what you get vs what you should have got...

    Regards,
    Edu