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.

DS90UB913Q / DS90UB914Q power up

Hi all,

   I have a board with a DS90UB914Q, driven by a iMX6 processor, connected to a camera board with DS90UB913Q. The two boards have independent power supplies.

The serializer/deserializer devices are operating in 10bit mode.

The issue I have now is that at power up the serializer have to be turned on after the deserializer has been initialized, otherwise there won't be any LOCK.

So, whenever I power up the system (processor board + camera board) I have later to turn off and on the camera board to have the serial link established.

Even if the cable is detached and reconnected this won't affect the deserializer to lock the signal. Only after having restarted the serializer the cable can be deconnected and reconnected causing the deserializer to unlock and lock again.

I have also used the DS90UB913 Demo Board to compare the behavior with the camera board and the result is the same: also the demo board have to be turned off and on in order to have the deserializer to lock the signal.

Thank you in advance.

   Andrew (Italy)

  • Hello Andew,

    What PCLK frequency are you running at and what exact cable type/length are you using? I am assuming that you are operating with an STP cable.

    Also, are you running your setup in external oscillator mode or PCLK mode?


    Have you tried the test setup with the camera board connected to the 913Q demo board and then the 913Q demo board connected to a 914Q demo board (without connecting the IMX.6)? If so, do you see any issues here? I would recommend trying this setup so that we can isolate the problem to the 914Q side of your design if the above setup passes. If it fails, then generally this would be an issue with the camera board.

    -Sean

  • Hi Sean,
    I am using a CAT5 twisted cable, same as ethernet cable, and I have an external 24 MHz clock.
    After having spent many hours trying to understand the problem I got that it seems due to the floating pins of the deserializer connected to the iMX6q.
    The point is this:
    - pins SEL, OEN, OSS_SEL, BISTEN are connected to GPIOs on the iMX6q properly configured with internal pull-up
    - at power up, the processor isn't booted yet and such pins remain floating
    - since the power supply is connected to both serializer (via power over cable) and to the main board (with iMX6q and deserializer), the power up will cause the deserializer to start in a unpredictable mode that will cause ALSO the serializer to hang!

    This seems strange, but it is like that.
    a) If I start the daughter board after the main board is booted, this won't happen.
    b) If the daughter board is started before the main board and the main board isn't booted yet (just uboot is started) the serializer will be hanged as well and it won't recover until it will be restarted.

    Here is how I have tested the situation at point "B":

    1) I have:
    - a main board with iMX6q
    - a demo board with serializer DS90UB913Q
    - a demo board with deserializer DS90UB914Q
    2) I connect the serializer demo board to the main board
    3) The main board is OFF
    4) I start the serializer demo board (power led is ON)
    5) I start the main board but uboot is configured to stop at the prompt, so Linux won't boot
    6) I detach the serial twisted cable from the main board and I connect it to the deserializer demo board (already powered up): there won't be any LOCK
    7) I restart the serializer demo board and the lock will come immediately on the deserializer demo board

    Now please look at this procedure where points :

    2) I connect the serializer demo board to the main board
    3) The serializer demo board is OFF
    4) I start the main board but uboot is configured to stop at the prompt, so Linux won't boot
    5) I start the serializer demo board (power led is ON)
    6) I detach the serial twisted cable from the main board and I connect it to the deserializer demo board (already powered up): LOCK comes immediately

    So it isn't exactly a matter of floating pins on the deserializer, what is happening is that at power up the deserializer is causing the serializer on the other side to jump in to a failure state and from such state it won't recover until it will be restarted.

    Looking forward

    Andrew
  • Hi Andrew,

    My apologies for a delayed replay. I am assuming you are sending power over the twisted cable with one twisted pair for data and the other for power. It might be helpful to look at your schematic offline to ensure that you have made the required schematic changes for transmitting power.

    I understand your issue and I believe it might have to do with voltage droop on the deserializer/main board side when the serializer side is powered on first. Have you probed the voltage on the JP4 header? This voltage is the external voltage coming over the coax cable from the deserializer/main board. If you are applying 5V over the line, this voltage will read between ~4.8V - 5V because there is usually a small drop over the cable. I would also recommend to probe the VDD_IO voltage close to the IC; this should read ~3.3V. Finally, probe the other VDD voltages close to the IC and these should all read ~1.8V.

    Lastly, please ensure that the OEN and OSS_SEL settings are configured according to our EVM User's Guide that I attached (I believe that you are using the non-A revisions of our devices; if you are using the A revision the revised User's Guide is on our website). This is in addition to ensuring the correct switch settings and jumper settings on both demo boards as according to this User's Guide (pages 6 - 13 of the attached).

    Is it required in your application to power on your serializer board first before the deserializer/main board? Also with just the camera sensor, 913Q demo board, and 914Q demo board (NO IMX6q connected) does it matter whether you start the serializer or the deserializer first? Both setups should work here without a restart if the IMX6q is not connected...

    -Sean

    OLD_EVM_User's_Guide.pdf

  • Hi Sean,
    actually, even if in our final product we will use power over cable, now, in the lab, we are giving power to the main board (with deserializer and iMX6) and to the camera sensor (with serializer) with 2 different and independent power supplies.

    What we have discovered during our tests is:
    1) if both main board and camera board are powered up at the same time there won't be any lock
    2) if camera board is powered up BEFORE the main board, there won't be any lock as well
    3) if camera board is powered up AFTER the main board, there will be the LOCK

    This is why we are focusing to understand point 2, as a particular case of point 1.

    I confirm that our schematic is the same as per your demo board. The EVM are rev. A.
    I confirm also that with just EVMs, no matter if the deserializer or the serializer is powered first, there will always be the LOCK.

    What we are wondering is why the power up of the deserializer will cause the serializer to go in a unpredictable state from which it will recover only with hardware reset. No power if passing over the cable in the test environment.

    Another possible issue could be if deserializer and serializer are exchanging encryption keys or something similar to authentication.
    Please have a look at the following situation:

    1) I have:
    - a main board with iMX6q and 2 deserializers (A properly configured and B not configured, I mean with pins SEL, OEN, OSS_SEL, BISTEN floating)
    - a demo board with serializer DS90UB913Q
    - a demo board with deserializer DS90UB914Q
    Every board is powered by an external and independent power supply.
    2) I connect the serializer demo board to the main board with the twisted cable (1 twisted pair data only, no power)
    3) I start the main board and let Linux booting
    4) I start the serializer demo board (power led is ON)
    5) I check the status register (0x1C) on the deserializer A connected to the cable. LOCK is OK.
    6) I detach now the cable and check status register: NO LOCK obviously
    7) I reconnect the cable and there will be LOCK again
    8) >>> I detach the cable and I connect it to the deserializer B !
    9) Status registers on both deserializer A dn B are showing NO LOCK.
    10 ) I reconnect the cable to the deserializer A and there won't be any LOCK again!
    11) At this point the serializer on the demo board is in an unexpected state and it won't recover until hardware reset.

    My question is: I understand that the deserializer B won't lock the signal from the serializer at point 9, but why at point 10 the deserializer A won't lock as well even if before (points 5, 6 and 7) it was properly working!
    My conclusion is that connecting the deserializer B (not configured) with the serializer will cause this to go in an unexpected state.

    The situation is exactly the same when the serializer demo board is powered up BEFORE the main board. When the main board will power up, the deserializer is not yet configured (because Linux isn't booted yet) and this will cause the serializer on the other hand of the cable to hang.

    Looking forward

    Andrew
  • Hello Andrew,

    This is definitely a weird issue that you are seeing. Just to confirm, I understand that deserializer B is OFF (but IMX.6 is booting?) above when you first try to connect the serializer. And then when you connect the serializer to the powered ON deserializer A, you don't obtain LOCK. However, are you sure that the default state of your OEN and OSS_SEL pins are set to be HIGH upon startup (see table 9 in the datasheet)? I believe you are stating that OEN and OSS_SEL pins are left floating on deserializer B because this device is not powered ON.

    If you are seeing LOCK though independent of startup sequence/order on the 913Q and 914Q EVM's, it just makes me wonder what either the deserializer's or the processor are causing here to send the 913Q into an unpredictable state.

    There are a few reasons why the serializer could go into a weird state:

    1. On deserializer A or B, you have enabled (pin=HIGH) RES, TESTEN, or BISTEN upon power-up.
    2. BIST Control (register 0x14[0]) = HIGH or RES=HIGH (this is an onboard switch) on the 913Q EVM.
    3. The registers on the 913Q EVM are not set to default. If you have made any changes, please let me know.

    Finally, have you tried switching the current deserializer devices with new ones on your main board? 914Q Samples can be ordered from our website.

    If the troubleshooting steps above don't fix the issue, a schematic review of your main board would be in order. Please let me know if you would like this done, the review would be via email and not the external forum.

    Best regards,
    Sean
  • Hi Sean,
    yes, you definitely got the point! Thanks a lot!
    We have discovered that at power up the deserializer BISTEN pin, that is floating, has a voltage of 2.6 V, so the serializer will enter into the BIST mode and it won't leave this mode until it will be turned off and on.
    Since we have a micro on the remote board, where the serializer is mounted, I was able to read the BIST Control register 0x14 and I found the bit 0 was HIGH, meaning BIST enabled!
    What I am doing now is to test the 0x14 register and check if BIST is enabled. If yes, the firmware on the remote board will turn off and on the PDB pin on the serializer causing it to restart.
    In such way as soon as the iMX6 will pull down the BISTEN pin on the deserializer, the remote serializer will go out from BIST mode (because of the PDB off and on) and it will detect the LOCK on the remote device (reg. 0x0C bit4 - RX Lock detected).

    Another solution could be to connect to ground the BISTEN pin on the deserializer in order to never let it to enter BIST mode.

    Thanks again for your help and precious support

    Andrew