ETH custom phy driver modifications

[DavidWahlberg]

Hi forum

I have a custom PCB with STM32F407 and a PHY+switch KSZ8863RLL. I am using CubeMX and cubeide, also LWIP. The physical connections have been verified by Microchip schematic- and board support program.

Instead of using MDIO to interface the PHY, I am using I2C (needed to access the advance registers, and also discussed: https://community.st.com/t5/stm32-mcus-products/eth-anybody-used-ksz8863rll/td-p/645122/page/3).

The switch part is functioning probably and I can successfully read and write registers. But I do not have a working ping up and running, yet. I can't measure any activity on RX/TX lines on the RMII interface.

My understanding is that i need to modify the LAN8742 driver, which is default by Cubemx. When debugging I come across this part:

in the ethernetif.c file.

My question is, is it enough to rewrite the writeRegister, ReadRegister, Init, etc: 

to use I2C instead of the MDIO?

Also, is it through the RMII interface that the MAC address of the STM is written (didn't find those lines in LAN8742_init.). 

Appreciate any advice to come a bit further to be able to ping my board :)

Best regards, David

[flightorlop]

Hi,

At first, see my discussion below this post: https://community.st.com/t5/stm32-mcus/how-to-use-the-lwip-ethernet-middleware-on-the-stm32h5-series/ta-p/691100

This all is by heart. If I remember correctly, you're using I2C so you're not able to use the MDIO/MDC (same pins on IC, set by strapping pins). So you don't need to use the IO_WriteReg etc functions. Just be sure that the switch HW is functioning correctly. I think it is also mention in the forum post you're linking, that the 3th port is the RMII from the switch to the controller, you could just assume it to be always connected.

Check out the ethernet_link_check_state and the GetLinkState part. And adjust the LAN8742 driver.

See linked post, for example you could always return STATUS_100MBITS_FULLDUPLEX for the link state.

I think this was it on the driver side, if the HW is good ofcourse.

The MAC address is set by the MX_ETH_Init, note: the STMs don't have a unique MAC address. You need to buy these and program them in the controller. For testing you could use the 96bit unique ID of the STMs

Regards.

[Pavel A.]

>  note: the STMs don't have a unique MAC address. You need to buy these and program them in the controller. For testing you could use the 96bit unique ID of the STMs

Exactly. You can buy MAC addresses on a i2c chip, such as Microchip  24AA02E48. Or generate locally administered addresses like this: (fast and dirty... on your own risk):

#include <stm32h7xx_hal.h>
// Generate MAC address from STM32 "unique ID":
// Fast and dirty, only for board bringup
// byte [1]=02, [1]=board type, [2..5] from "unique ID"[0]
void generate_MAC_addr(uint8_t addr[6], uint8_t a1)
{
    addr[0] = 0x02;
    addr[1] = a1;
    uint32_t u = HAL_GetUIDw0();
    __UNALIGNED_UINT32_WRITE(&addr[2], u);
}