www.beck-ipc.comwww.beck-ipc.com  | ImprintImprint
FAQFAQ  | SearchSearch  |

ETH1 not working - TXCLK not generated

Questions and discussions about the operating system RTOS-LNX and the corresponding C-LIB.
Yes, with or without the cable we see a momentary flicker on ETH1's one LED. Then it goes off.

One more input for your information. Currently we have bypassed RESET_IN signal to SC145. i.e SC145 is directly powered on/off without the resetting circuitry. Will it have any impact ? Anything to be checked in this regard ?


Hello Sharmila,

both LEDs on ETh1 should be light up during the bootloader execution when a cable is connected.
This should happen at the same time that both LEDs on ETH0 are activated, when a cable is connected there too.

It's possible that the traffic LED of ETH1 or ETH0 is shortly activated directly at power-on, but that's not what I mean and what we're looking for. Please compare the behavior with the DB150 when both Ethernet cables are plugged, because it's a bit hard to explain how these LEDs behave normally.
If the PHY link LEDs do not show the same behavior on your board, there's maybe some problem with VCC or GND?

If no cable is connected, you should be able to message some activity on TXP/TXN if the PHY is alive, at least as long as the TXCLK is generated.

As we only have your schematics and not the layout, we can only assume that you have connected the TH1-TH9 pins to the bottom paddle of the PHY and that GND is really applied here.

Best Regards,
André Pribil
Software Development
Beck IPC GmbH

We've checked the VCC and GND supply. TH1-9 pins of PHY and GND also connected .

The LED behaviour is as mentioned above and different from DB150 where both the LEDs lit up after bootup when connected with cable.

Any other suggestion to check things further ?
Do you want us to send the layout ?



if the LEDs do not act like on the DB150, it looks like the PHY does not come up correctly.
This really looks like a hardware issue. However, from the schematics we did not see any fault so far.
If you already checked the layout, I doubt that we would find something here.

Sorry, but I'm running out of ideas.

André Pribil
Software Development
Beck IPC GmbH

Dear Andre ,

This is to inform that, the ETH1 interface was seen up when we changed the PHY chip : KSZ8061RND.

But, we are not able to ping the same,ETH0 is as ausual reachable.

following are the contents of CHIP.INI :



; this is GM_ON/OFF for FM_RTU
; as per DB150:Dk151

Also, one more observation:

When ETH0,ETH1 were of the same netmask,network id (, only ip addresses differed ( eth0:, eth1: ), then it pinged to ETH1 ip, even without ETH1 cable connected.

FYI, in 'flm dmesg' log we have seen following entry, (though finally ethernet:01,02 PHY driver [Micrel KSZ8061] attched messages can be seen normally at the end .)

fec 20b4000.ethernet eth1 (uninitialized): Invalid MAC address: 00:00:00:00:00:00
[ 0.380793] fec 20b4000.ethernet eth1 (uninitialized): Using random MAC address: 76:1d:ad:89:47:c4

Can you give further hint why the ETH1 phy is not doing any data activity ?


Hello Sharmila,

if you don't use different subnets on the two interface, the behavior you're seeing is expected.
An outgoing packet to a host is checked against the configured subnets in the system.
The first matching interface is used to send out the packet. If no subnets matches the packet is send to the gateway. That's how a TCP/IP stack works.

Now that the PHY device is recognized, what's the link status of the port?

Best regards,
André Pribil
Software Development
Beck IPC GmbH

Agreed about the behaviour related to TCP/IP stack and about the default gateway path .

That is why basically it just used ETH0 for communication when both the interfaces were on the same subnet.

And whenever ETH1 subnet is diffrent , it is not pinging . That makes me think ETH1 interface is not doing any data activity. In this case the link of ETH1 is up.



Return to RTOS-LNX

Who is online

Users browsing this forum: No registered users and 1 guest