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.

DP83TC812S-Q1: Transceiver behavior – INH line not pulled low after sleep request

Part Number: DP83TC812S-Q1


Tool/software:

We are using a VN5611 interface together with CANoe to send sleep/wake-up requests (using ethSetPhyState(...)) to a TI_DP83TC812S transceiver.
Setup and observations:
  • The sleep negotiation on activity feature is disabled (bit 11 of register LPS_CFG2 = 0).
  • We poll the LPS_STATUS register every 10 ms to monitor the transceiver state.
  • When sending a sleep request from CANoe, we observe the following sequence in the monitored status:
    • The transceiver transitions from Normal → Sleep Ack (seen via LPS_STATUS).
    • The link transitions to Link Down (observed in CANoe).
    • Shortly after, the status register reads 0xFF (seen via LPS_STATUS ). We interpret this as the transceiver being in sleep mode.
  • The WAKE pin remains low (0 V) at all times.
  • After receiving LPS_STATUS = Sleep Ack, our application transitions from Normal mode to Sleep mode. The microcontroller remains powered, but no activity is expected on the SGMII interface.
However, when checking with an oscilloscope, I noticed that the INH line is not pulled to GND after the sleep request — it remains high.
Could you please clarify:
  1. Is 0xFF the expected value of LPS_STATUS when the device is in sleep mode?
  2. Should the INH pin be driven low once the transceiver enters sleep?
  3. Is there any additional configuration required to make the INH line reflect the sleep state?

Overall system image (radar system):

Oscilloscope image:

  • Hi Biria,

    I will check with the team about these questions and get back to you as soon as possible.

    Best regards,

    Greg

  • Hi!

    I have a related question: if my microcontroller is requested to enter sleep mode (by another source), and I also want to put the transceiver to sleep, how can I achieve this? We tried writing LPS_CFG3 = 2, but it doesn’t seem to work.

    Note: we’ve also tried forced sleep — it worked, but we cannot recover from it using a simple wake-up request (WUP), so we excluded this solution.

    Are there specific pins or register settings we should use to properly enter sleep mode from the MCU? Additionally, regarding the WAKE pin: can this pin be used only to request a local wake-up, or can it also be used to request sleep?

  • Hi Biria,

    Yes, if the device is in sleep mode, we expect to read back 0xFF. It is strange that you are seeing INH high during sleep, it should be low. Is there a more detailed schematic for this device that you could share? Also, after waking the PHY back up, does the register read make sense? For your second question, are you referring to Local Sleep, as described here?

    Best regards,

    Greg

  • Hello, 

    I'll answer your questions one by one:

    1. "Is there a more detailed schematic for this device that you could share?" → What kind of details are you looking for? I can check whether they can be shared.

    2. "After waking the PHY back up, does the register read make sense?" → Yes, after waking up, the register read makes sense — it returns to its normal value.

    3. "For your second question, are you referring to Local Sleep, as described here?" → Yes. We tried to implement that by writing LPS_CFG3 = 0x002 (Sleep request), but the transceiver remains in Normal Operation.

    We also tried entering sleep mode by writing A2D_REG_68 to forced sleep (bits 2 and 3 set to 1). In this case, the transceiver does enter sleep mode, but we are unable to wake it up remotely.

  • Hi Biria,

    1. The full configuration of all the PHY's pins in a schematic would be ideal for debugging. 

    2,3. Thank you for clarifying, that is not standard behavior of the device.

    I will look internally to see if I can find a potential cause of this. If it is possible to send a full schematic of the PHY that would also be helpful.

    Best regards,

    Greg

  • Hello Gregory

    I will send you the schematics by email as they are confidential.

    can you have a look at this please as this becomes urgent.

    Best regards
    Martin, Ti FAE