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

ETH1 not working - TXCLK not generated

Questions and discussions about the operating system RTOS-LNX and the corresponding C-LIB.
Hi,

We are in the testing phase of our SC145 based board. We have successfully powered on our board and seen the console message on UART1 serial port. Also we have successfully configured and accessed ETH0 interface.

The firmware details are like this :
Bootstrap version V1.12
@CHIP-RTOS-LNX SC1x5 V01.18, Build: Dec 11 2017 20:16:55 #444


The issue is with ETH1 interface. In the CHIP.INI we have done following entries.( which do work successfully on the evalution kit DK-151, RTOS v1.19 beta)



[IP]
GATEWAY=192.168.1.1
NETMASK=255.255.255.0
ADDRESS=192.168.1.75
DHCP=0

[IP_ETH1]
GATEWAY=192.168.1.1
NETMASK=255.255.255.0
ADDRESS=192.168.1.95
DHCP=0
ETH_ENABLE=1

But the ETH1 does not work. We found that the 50MHz clock on the pin-67 TXCLK of SC145 is not getting generated.Fail to understand why. Without this clock the ETH1 conencted through RMMI won't work.

I am assuming that if we isolate this pin 67 from external eth1 interface circuitry,i.e. irrespective of other circuitry the TXCLK should still show the 50 MHz signal. Please correct me, if I am wrong here.

What must be the problem ? Any suggestion ?


..Sharmila

Hello Sharmila,

yes, you should see a 50 MHz signal on the Pin67 TXCLK signal.
Did you try to isolate this pin from your external PHY circuit?
If this pin is isolated and still does not show a 50 MHz signal, the SC145 is probably damaged, for whatever reason.

Best regards,
André Pribil
Software Development
Beck IPC GmbH

Unfortunately I am seeing exactly the same behaviour on another of our board .too.
Strangely ETH0, UART1, UART3, UART5 ,SDcard working ok.So, still there is possibility of damage ? Can it be related to RTOS version ?

..Sharmila

Hello Sharmila,

I think that the RTOS version should play no role here. The TXCLK signal is already activated in the bootloader.
Your bootloader version is V1,12, which is the latest released version. This should be ok.

It's still not clear to me whether you have isolated the pin and still don't measure the 50 MHz clock.
If your external PHY circuit is still connected to this pin, something could drive against this signal.

Best regards,
André Pribil
Software Development
Beck IPC GmbH

Hello Sharmila,

please check the signal directly after a reset. It is possible that the signal gets deactivated later by the RTOS, when there's a problem with the PHY.

Best Regards,
André Pribil
Software Development
Beck IPC GmbH

Yes, the TXCLK is isolated from the external circuit.
Still, I will check after reset again..

Yes, we see 50MHz signal on reset ,which gets deactivated later.

Curently what we have isolated is TXCLK from the KSZ8061RND circuitry. ETH1-TXEN,TXD1,TXD0,RXD1,RXD0,RXER,RESOUT,MDIO,MDC,CRS_DV are still connected to SC145. Do you suggest to disconnect these too, to check the 50Mhz signal ?

..sharmila

Hello Sharmila,

so I think that we now excluded a problem with the chip TXCLK signal. Good.
The signal gets deactivated if the ETH1 interface is not enabled in the CHIP.INI, which is obviously not the case in your configuration, or if some error with the PHY is detected, which I think is happening here.

I would suggest to reconnect the signal and check the Linux kernel outputs to see if some error message is printed during the PHY detection. Please restart the system, wait some seconds after it has booted and then execute the following command and send me the outputs.

Code: Select all
flm dmesg


Best regards,
André Pribil
Software Development
Beck IPC GmbH

sending you the log on your mail-id
..sharmila

Thanks, I received it.

There's no message about the ETH1 PHY in the log, no error and no success message.
Normally, something like this should appear if the ETH1 interface is enabled.

Code: Select all
[   10.371069] Micrel KSZ8061 20b4000.ethernet:02: attached PHY driver [Micrel KSZ8061] (mii_bus:phy_addr=20b4000.ethernet:02, irq=-1)
[   10.383074] IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready


It seems like the PHY is not detected at all.

I have taken a short look into your schematics diagram.
Is C64 on X1 of the PHY populated/mounted?
In our designs this capacitor is only in the schematics and not on the board.
Maybe you can try to remove it, if it is mounted.

Additionally, you may check the signal level at the RESET input of the PHY.

Best regards,
André Pribil
Software Development
Beck IPC GmbH

Seem to be a confusion about the log here. In the sent log dmesg_2.txt, I can see the line below.

[ 6.677520] Micrel KSZ8061 20b4000.ethernet:01: attached PHY driver [Micrel KSZ8061] (mii_bus:phy_addr=20b4000.ethernet:01, irq
=-1)

Can you please confirm ?


..Sharmila

Oh ! for ETH1 ,it should be ethernet:02: attached
PHY driver... Is it so ? I will recheck.

1> Meanwhile , we also disconnected the capacitor and re-tested. The behaviour is same i.e. the 50MHz signal gets deactivated later.

2> Also, I checked the log. As said in above post, it shows entry for ethernet:01. Is one more entry for ethernet 02 i.e. ETH1 is expectecd ?

3> In the same log I also see following lines.

[ 0.381035] fec 20b4000.ethernet eth1 (uninitialized): Invalid MAC address: 00:00:00:00:00:00
[ 0.381160] fec 20b4000.ethernet eth1 (uninitialized): Using random MAC address: 62:5b:8e:0d:cd:17
[ 0.382551] libphy: fec_enet_mii_bus: probed
[ 0.385650] fec 20b4000.ethernet eth1: registered PHC device 0
[ 0.389301] pps pps1: new PPS source ptp1
[ 0.420646] libphy: fec_enet_mii_bus: probed
[ 0.422043] fec 2188000.ethernet eth0: registered PHC device 1


ETH1 not initialsed, but PHC device is registered for it. This has got any relevance for our problem ?

4> Also, during the boot there is one serialization error is reported as below.
ERROR: Processing AUTOEXEC.BAT is canceled since device has
invalid serialization information!

..Sharmila

Hello Sharmila,

in the log the following entries are expected: "ethernet:01" for ETH0 and "ethernet:02" for ETH1.
The "ethernet:02" message is missing. The other log messages are all ok, also the "unintialized" message.

The serialization problem was already discussed on an email channel between Mr. Vedder and Muley Pratik.
It's a mistake we made during manufacturing. Sorry. However, as these devices will be sent to Beck anyway for receiving the WEB-PLC software, this will be corrected then by us here. This issue does not have any impact on the ETH1 problem.

Best regards,
André Pribil
Software Development
Beck IPC GmbH

Hello Sharmila,

when you connect a Ethernet cable to ETH1 and a switch, does this ETH1 PHY link and traffic LEDs light up after a reset? Normally, if the PHY is alive, during the bootloader execution the PHY link LED should report a link. Later, when the kernel is started, the link will disappear again. You can compare the behavior with the DB150.

Best regards,
André Pribil
Software Development
Beck IPC GmbH

Next

Return to RTOS-LNX


Who is online

Users browsing this forum: No registered users and 0 guests


cron