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.

Can I configure/wire the DP83848 speed LED to be off when no link?



Hi:

From a previous post, Patrick explained the DP83848 speed LED behavior at power up:

"After power up, with no software interaction, default straps [...], and no connection to the RJ-45, the [DP83848] device should be configured for Auto-Negotiation with no link and no activity. In this configuration, the link and activity LEDs should not be lit, but the speed LED should be lit. This is because the speed LED indicates 100Mbps functionality and in Auto-Negotiation mode, the 100Mbps receiver is active."

I have a single-port 10/100 design in production that uses the DP83848 device, and the speed LED behaviour is consistent with this description.

On a prototype design, I am using the DP83848 device to add an additional (secondary) 10/100 port. The primary port on the design uses a different (non-TI) PHY that displays a different power up behavior: the speed LED is not lit when there is no link.  The behavior of "gating" or turning off the speed LED when link is not present is standard across the other PHYs I have used. The lit speed LED on the DP83848 causes an inconsistency between the two ports.

Is there any way to turn off the DP83848 speed LED when there is no link? I would prefer a PHY register-setting method, however at this stage I am open to board-level gating of the signal as well.

Thanks,
Greg

  • Greg,

    The Speed LED would more accurately be named the 100M Speed LED.  What it is indicating when lit is that the device, specifically the receiver of the device, is configured for 100M mode.  When the Speed LED is not lit, it indicates that the device is in 10M mode. 

    Below I will describe three possible ways to provide the functionality you described:

    1. Gate the Speed LED on the board with a CMOS gate or with some bipolar devices to prevent the Speed LED from lighting until the Link LED lights.  It requires some additional components, but it is simple and it will provide "real time" LED updates.
    2. Use the LEDCR (register address 0x18 to explicitly drive the Speed LED high or low.  This would require occasional register accesses to change the state of the LED depending on the link state.  For the 48 pin DP83848 devices, the device could be configured to signal an interrupt via the interrupt pin on a change of link status.  This interrupt could be used as a trigger to update the LEDCR. 
    3. Configure the device for 10M operation.  This would obviously only work for a limited number of applications.

    Does the LEDCR approach sound reasonable for your application?  Would it be worthwhile to dig into the detail a bit deeper or would the board level approach be more suitable?

    Patrick

     

  • Hi Patrick:

    Thanks for the response. In our application the LEDCR approach is not preferred as we desire to keep the generic kernel sources (DP83848 TI/National PHY driver) as delivered and unmodified to avoid maintenance burden.  Neither is the 10M operation only approach preferred, since we need both 10M/100M auto-negotiation. Therefore, for our application a board-level gating of the (100M) Speed LED using link status is preferred.

    Our application must provide on the port a Link/Activity LED (ON when link is good, and BLINKING when TX or RX is active) as well as a Speed LED (OFF when link is not present, and ON (steady) if link is good and speed is 100M).

    We are operating in LED Mode 2, with our Link/Activity LED driven by LED_LINK and our Speed LED driven by LED_SPEED.

    If you would, could you please propose a method to gate LED_SPEED when the link is not good, given that in our application the LED_LINK signal will be blinking during TX/RX activity?

    Thanks,
    Greg

  • Greg,

    The fact that the Link LED is also blinking to indicate activity complicates matters.  This is a novel implementation so rather than try to define the optimal method too strictly, I would prefer to help define the problem and the variables involved to allow you to determine a solution with which you are comfortable. 

    Based on your preferred configuration, I believe you will strap the LED pins high in order to enable Auto-Negotiation and advertise 10/100 full and half duplex.  Could you confirm?  Assuming that is the preferred configuration, the device will configure the LED pins as active low drivers due to the pull up resistors. 

    When the Link LED blinks to indicate activity, the blink rate will be ~6Hz.  One possibility would be to low pass filter this with an RC and provide the filtered voltage to a comparator input.  The output of the comparator could then be logically combined with the output of the Speed LED pin to drive the actual Speed LED. 

    Something like this would require a couple gates and a couple passives, but should provide the functionality you need.  Does this sound reasonable?

    Patrick

  • Hi Patrick:

    In our application we are strapping the LEDs high to enable Auto-Negotiation and advertise 10/100 full and half duplex.

    Thanks for providing a suggested implementation to gate the speed LED. We are currently breadboarding the following circuit. We are buffering the Link LED driver with an inverting buffer (SN74LVC1G04DCKR) and RC filtering the buffered output at ~4Hz. The buffered/inverted/filtered signal is then used to drive the base of a NPN transistor (2N3904) used as a switch. The Speed LED driver is connected to the emitter, and the collector is connected to the actual Speed LED on the port.

    I will let you know how this tests out.

    Thanks,

    Greg

  • Hi Patrick:

    In order to gate the speed LED (so that it is OFF when link is not present yet still indicates the proper speed when link is present) we ended up using the following circuit. The devices were already in use in other parts of our design.

    The Link LED driver signal is monitored using a reset monitor with active low output (MAX809). The output of the monitor device is fed through an inverting buffer (SN74LVC1G04DCKR) and the buffered/inverted signal is used to drive the base of a NPN transistor (2N3904) used as a switch. The Speed LED driver is connected to the emitter, and the collector is connected to the actual Speed LED on the port.

    This design could be further simplified by using a reset monitor with active high output, eliminating the inverting buffer, however these parts were chosen for design reuse in the circuit.


    Kind regards,
    Greg