dirvers: eth_stm32_hal: No interrupt is generated on the MII interface.

[ghost]

Describe the bug After completing the stm32f745vet mcu board setup, we are testing Ethernet operation using mii interface and spi communication with ksz8863 phychip of microchip.
Through spi communication, we confirmed that the register settings of ksz8863 phychip, such as checking the connection status of the LAN line, are well established. In addition, the parts related to pinmux were additionally modified to support the mii interface. It was confirmed that the clock generation of 25MHZ at PA1 (ETH_MII_RX_CLK) and PC3 (ETH_MII_TX_CLK) pins and the waveform at ETH_MII_RXD[0..3] pins occur when the LAN wires are connected. The interrupts did not occur in the rx_thread function of dirvers:eth_stm32_hal.c. so semaphore cannot be obtained. In the normal operation development board stm32f745g_disco, supported by zephyr,
interrupts occur when the LAN line is connected while rx_thread is running, and semaphore is acquired and eth_rx function is executed. I don't know why interrupts don't happen. I'd appreciate your help.

To Reproduce Steps to reproduce the behavior:

1. mkdir build; cd build
2. cmake -DBOARD=stm32f745ve ..
3. west flash

Expected behavior When the LAN cable is connected, an interrupt will occur to obtain semaphore and perform the eth_rx function.

Logs and console output Booting Zephyr OS version 2.2.99

[00:00:05.421,000] <inf> eth_stm32_hal: Register 0 (0x00): ksz8863 Chip ID0 = 0x88
[00:00:05.431,000] <inf> eth_stm32_hal: MAC 02:80:e1:00:15:78
Single-threaded TCP echo server waits for a connection on port 4242...

Environment (please complete the following information):

• OS: Linux ubuntu 18.04
• Toolchain: zephyr-sdk-0.11.1
• Commit SHA or Version used: 2d9baf97f9fbda8cdd3eb05a82b505333c196cf9

Additional context The register initialization setting of ksz8863 phychip is completed, and it has been confirmed that chip id, connection status check of LAN line, etc. is read by spi communication.
And we checked and started the normal operation of samples/net/socket/echo/socket_echo.c through the sm32f746g_disco board. To support the mii interface, CONFIG_ETH_STM32_HAL_MII=y was set to and drivers/pinmux/stm32/pinmux_stm32f7.h was added correctly. ~/zephyrproject/zephyr/boards/arm/stm32f745ve/pinmux.c:

#ifdef CONFIG_ETH_STM32_HAL
    //{STM32_PIN_PA2, STM32F7_PINMUX_FUNC_PA2_ETH}, /* ETH_MDIO */
    //{STM32_PIN_PC1, STM32F7_PINMUX_FUNC_PC1_ETH}, /* ETH_MDC */

    {STM32_PIN_PC3, STM32F7_PINMUX_FUNC_PC3_ETH}, /* ETH_MII_TX_CLK */
    {STM32_PIN_PB12, STM32F7_PINMUX_FUNC_PB12_ETH}, /* ETH_MII_TXD0 */
    {STM32_PIN_PB13, STM32F7_PINMUX_FUNC_PB13_ETH}, /* ETH_MII_TXD1 */
    {STM32_PIN_PC2, STM32F7_PINMUX_FUNC_PC2_ETH}, /* ETH_MII_TXD2 */
    {STM32_PIN_PE2, STM32F7_PINMUX_FUNC_PE2_ETH}, /* ETH_MII_TXD3 */
    {STM32_PIN_PB11, STM32F7_PINMUX_FUNC_PB11_ETH}, /* ETH_MII_TX_EN */

    {STM32_PIN_PA1, STM32F7_PINMUX_FUNC_PA1_ETH}, /* ETH_MII_RX_CLK */
    {STM32_PIN_PC4, STM32F7_PINMUX_FUNC_PC4_ETH}, /* ETH_MII_RXD0 */
    {STM32_PIN_PC5, STM32F7_PINMUX_FUNC_PC5_ETH}, /* ETH_MII_RXD1 */
    {STM32_PIN_PB0, STM32F7_PINMUX_FUNC_PB0_ETH}, /* ETH_MII_RXD2 */
    {STM32_PIN_PB1, STM32F7_PINMUX_FUNC_PB1_ETH}, /* ETH_MII_RXD3 */
    {STM32_PIN_PA7, STM32F7_PINMUX_FUNC_PA7_ETH}, /* ETH_MII_RX_DV */
    {STM32_PIN_PB10, STM32F7_PINMUX_FUNC_PB10_ETH}, /* ETH_MII_RX_ER */
    {STM32_PIN_PA0, STM32F7_PINMUX_FUNC_PA0_ETH}, /* ETH_MII_CRS */
    {STM32_PIN_PA3, STM32F7_PINMUX_FUNC_PA3_ETH}, /* ETH_MII_COL */
#endif /* CONFIG_ETH_STM32_HAL */

~/zephyrproject/zephyr/samples/net/sockets/echo/prj.conf:

# General config
CONFIG_NEWLIB_LIBC=y

# Networking config
CONFIG_NETWORKING=y
CONFIG_NET_IPV4=y
CONFIG_NET_IPV6=n
CONFIG_NET_TCP=y
CONFIG_NET_SOCKETS=y
CONFIG_NET_SOCKETS_POSIX_NAMES=y

# Network driver config
CONFIG_TEST_RANDOM_GENERATOR=y

CONFIG_SPI=y

CONFIG_NET_L2_ETHERNET=y
CONFIG_ETH_STM32_HAL=y
CONFIG_ETH_STM32_HAL_MII=y
CONFIG_ETH_KSZ_MII_SPI=y

# Network address config
CONFIG_NET_CONFIG_SETTINGS=y
CONFIG_NET_CONFIG_NEED_IPV4=y
CONFIG_NET_CONFIG_MY_IPV4_ADDR="192.168.65.125"
CONFIG_NET_CONFIG_MY_IPV4_NETMASK="255.255.0.0"
CONFIG_NET_CONFIG_MY_IPV4_GW="192.168.1.1"

CONFIG_LOG=y

What should I do? PA1 (ETH_MII_RX_CLK) and PC3 (ETH_MII_TX_CLK) clocks are occurring at 25MHZ, and when the LAN is connected, signals are generated at the ETH_MII_RXD [0..3] [PC4, PC5, PB0, PB1] pins, and why is there no interrupts at MCU? I'm not sure what's wrong. What do you think is the problem?

[erwango]

@lochej @Nukersson would you have time to look at this ?

[lochej]

@lochej @Nukersson would you have time to look at this ?

I'd be glad to help but not sure I'll be able to, I don't own any F7 board to troubleshoot the ethernet 😫

[lowlander]

Booting Zephyr OS version 2.2.99

@wngur300 Can you try with master ?

[KozhinovAlexander]

Hello @wngur300 and thank you for your question.

I'll try to answer/understand better your questions/suggestions step by step:

Interrupt does not occur

Have you looked at eth_isr() in eth_stm32_hal.c? Is something happened here after LAN cable connection?

Booting Zephyr OS version 2.2.99

See previous answer. Try with latest master of Zehyr or at least replace eth_stm32_hal.c by one from master.

In the normal operation development board stm32f745g_disco, supported by zephyr, interrupts occur when the LAN line is connected while rx_thread is running, and semaphore is acquired and eth_rx function is executed.

Are you sure? In my opinion there is only stm32f746g_disco and it definitely has RMII (see Sheet 12 of Shematic). If the interrupts are still not occur, you need to look further on section 38.7 of RM0385 Rev 8 for example. Try take a look at register of your stm32f7 after cable connection. I would say, that MII is not fully tested within Zephyr for stm32 platform and could be your problem here!

Last important thing: The current driver was not tested with MII interface, cause (kick me if I am wrong 😄) nobody of active participants of stm32 eth driver development thread does not have board with MII interface 😄

[ghost]

Booting Zephyr OS version 2.2.99

@wngur300 Can you try with master ?

*** Booting Zephyr OS build zephyr-v2.4.0-542-g0d04754652e9  ***  

Even in the master commit above, interrupt does not occur when the LAN cable is connected..

[ghost]

Have you looked at eth_isr() in eth_stm32_hal.c? Is something happened here after LAN cable connection?

When debugging, the eth_isr() function is not executed even if the LAN line is connected.

See previous answer. Try with latest master of Zehyr or at least replace eth_stm32_hal.c by one from master.

*** Booting Zephyr OS build zephyr-v2.4.0-542-g0d04754652e9  ***  

Even in the master commit above, interrupt does not occur when the LAN cable is connected..

Are you sure? In my opinion there is only stm32f746g_disco and it definitely has RMII (see Sheet 12 of Shematic). If the interrupts are still not occur, you need to look further on section 38.7 of RM0385 Rev 8 for example. Try take a look at register of your stm32f7 after cable connection. I would say, that MII is not fully tested within Zephyr for stm32 platform and could be your problem here!

I have a stm32f746g_disco board that supports Ethernet from zephyr to rmii interface, so I checked its operation.
On the stm32f746g_disco board, an interrupt occurred when the rx_thread was executed and the LAN line was connected, but on the test board stm32f745bet mcu connected by mii interface, no interrupt was generated. It was confirmed that 25 mhz waveforms were occurring at eth_mii_tx_clk, eth_mii_rx_clk pins, and that waveforms also occurred at eth_rx pins when the LAN line was connected.

And I debugged the MAC, DMA register, which is initialized by sm32f7xx_hal_eth.c, comparing it with the stm32f746g_disco board, but there seemed no particular difference or problem.

[KozhinovAlexander]

And I debugged the MAC, DMA register, which is initialized by sm32f7xx_hal_eth.c, comparing it with the stm32f746g_disco board, but there seemed no particular difference or problem.

There should be no difference between stm32f7 series.

but on the test board stm32f745bet mcu connected by mii interface, no interrupt was generated. It was confirmed that 25 mhz waveforms were occurring at eth_mii_tx_clk, eth_mii_rx_clk pins, and that waveforms also occurred at eth_rx pins when the LAN line was connected.

Seems to be, that MII is not properly tested with current stm32 eth driver. Since neither I nor @lochej have any board with MII, we can not investigate it properly.

Are you able to read whole register stm32f7 peripheral register set with your debugger? Here seems to be something wrong with eth peripheral configuration within the SoC.

[ghost]

Are you able to read whole register stm32f7 peripheral register set with your debugger? Here seems to be something wrong with eth peripheral configuration within the SoC.

I'm sorry but I didn't exactly understand reading the sm32f7 peripheral register. For example, is it correct to ask if the ETH_TypeDef member variable MACSR value can be read..?

[KozhinovAlexander]

Are you able to read whole register stm32f7 peripheral register set with your debugger? Here seems to be something wrong with eth peripheral configuration within the SoC.

I'm sorry but I didn't exactly understand reading the sm32f7 peripheral register. For example, is it correct to ask if the ETH_TypeDef member variable MACSR value can be read..?

I mean, just reading ETH_MACCR register of MAC peripheral for example, to see which interrupts MAC module generates on register level for example.

Take a look also here. Somebody seems to have almost same problem with MII and FreeRTOS. Maybe it helps you.

My ideas:

1. Check all your ETH_MAC registers, if they correctly configured by the driver.
2. Check if your ETH_PHY ksz8863 has correct settings in registers.
3. Try to understand it right, how your ETH_PHY propagates interrupts to stm32f7 and which hardware part of stm32f7 is responsible for interrupts generation.

I hope, I can bring you on right way. I would like to test your system, but I do not own board with MII.

Maybe you want provide a PR with correct MII settings and ksz8863 phy support?

[ghost]

1. Check all your ETH_MAC registers, if they correctly configured by the driver.

1. The captured images below are values written in mac, dma memory of the test board consisting of the stm32f745ve mcu and ksz8863 phychips (MII interface). I tried debugging in the rx_thread function.

2. Debugged and compared on the stm32f746g_disco board operating normally with the rmii interface. The mac, dma register initialization is the same without any particular difference.

2. Check if your ETH_PHY ksz8863 has correct settings in registers.

I thought that the basic initialization of the phychip register was successful and that the waveform would come from the rx data pins when the LAN wires were connected..

3. Try to understand it right, how your ETH_PHY propagates interrupts to stm32f7 and which hardware part of stm32f7 is responsible for interrupts generation. I hope, I can bring you on right way. I would like to test your system, but I do not own board with MII. Maybe you want provide a PR with correct MII settings and ksz8863 phy support?

If normal operation is completed, I will provide pr. I'm not ready because I'm testing right now.

MAC,DMA registers are initialized,and signals are generated from ethernet rx data pins,so I think the eth_isr function should be executed. I don't do the eth_isr function at all. I don't know what the problem is.

[KozhinovAlexander]

@wngur300 According to your MACMIIAR = 0x50 value the Bits 4:2 (aka CR - clock range) configured for 150-216 MHz ( HCLK/102 ) MDC clock range (see ETH_MACMIIAR of RM0385 Rev 8 on page 1603). Even if you use SPI instead of SMI for KSZ8863 configuration you should probably try to configure ETH_MACMIIAR for correct clock range first.

Also take a look at SYSCFG_PMC register (see section 38.4.4 of RM0385 Rev 8 on page 1539).

I would say, you should carefully check all MAC registers first according to reference-manual.

[ghost]

@wngur300 According to your MACMIIAR = 0x50 value the Bits 4:2 (aka CR - clock range) configured for 150-216 MHz ( HCLK/102 ) MDC clock range (see _ETH_MACMIIAR_ of RM0385 Rev 8 on page 1603). Even if you use SPI instead of SMI for KSZ8863 configuration you should probably try to configure _ETH_MACMIIAR_ for correct clock range first.

Also take a look at _SYSCFG_PMC_ register (see section 38.4.4 of RM0385 Rev 8 on page 1539).

I would say, you should carefully check all MAC registers first according to reference-manual.

My board has 8MHZ oscillator. My board setting is as follows.

CONFIG_SOC_SERIES_STM32F7X=y
CONFIG_SOC_STM32F745XX=y
# 216MHz system clock
CONFIG_SYS_CLOCK_HW_CYCLES_PER_SEC=216000000

CONFIG_SERIAL=y

# console
CONFIG_CONSOLE=y
CONFIG_UART_CONSOLE=y

# enable pinmux
CONFIG_PINMUX=y

# enable GPIO
CONFIG_GPIO=y

# clock configuration
CONFIG_CLOCK_CONTROL=y

# Clock configuration for Cube Clock control driver
CONFIG_CLOCK_STM32_HSE_CLOCK=8000000
CONFIG_CLOCK_STM32_SYSCLK_SRC_PLL=y
# use HSE as PLL input
CONFIG_CLOCK_STM32_PLL_SRC_HSE=y
# produce 216MHz clock at PLL output
CONFIG_CLOCK_STM32_PLL_M_DIVISOR=4
CONFIG_CLOCK_STM32_PLL_N_MULTIPLIER=216
CONFIG_CLOCK_STM32_PLL_P_DIVISOR=2
CONFIG_CLOCK_STM32_PLL_Q_DIVISOR=2
CONFIG_CLOCK_STM32_AHB_PRESCALER=1
CONFIG_CLOCK_STM32_APB1_PRESCALER=4
CONFIG_CLOCK_STM32_APB2_PRESCALER=2

The stm32f746g_disco board, which operates normally with an RMII interface, also operates with a system clock of 216 mhz. It has been confirmed that the SYSCFG_PMC register is also set to MII MODE.

[KozhinovAlexander]

Thanks for the info. Then I can't do more here, since it is difficult to test without appropriate HW.

[erwango]

@wngur300 Since the issue you report seems specific to your board set up, I think it will be useful you could share more info to help in support. In order not to be blocked, I propose the following:

• Share your board support in a draft PR, so code review could be done
• Share your issue on stcommunity.com as maybe some other could face similar issue on the specific SoC you're using.

[ghost]

@wngur300 Since the issue you report seems specific to your board set up, I think it will be useful you could share more info to help in support. In order not to be blocked, I propose the following:

• Share your board support in a draft PR, so code review could be done
• Share your issue on stcommunity.com as maybe some other could face similar issue on the specific SoC you're using.

It was a problem of hardware configuration. I solved it. Thank you.

[erwango]

@wngur300 Great, you can thanks @Nukersson since I didn't did much :-) Is that ok if we close the ticket then ?

[KozhinovAlexander]

@wngur300 Can you please explain in short, what the problem was? Maybe somebody will face same problem later and your experience can help?

[KozhinovAlexander]

@erwango there is no action from author and he acknowledged solution. Should we close it?

[erwango]

@Nukersson Sure, closing it now.

[ghost]

@wngur300 Can you please explain in short, what the problem was? Maybe somebody will face same problem later and your experience can help?

Sorry for replying late. Let me tell you the problem.

1. PC1(MDC) incorrectly connected with PB10(rx_err) pin. 2. I didn't use MIIM interface and I used SPI to interface with phy chip, and there was an MIIM function defined in pinmux. 3. Do not use rx_errpin on ksz8863 chips.

There is a record of my definition of pinmux above.

[vandita5]

Hey, I'm having a similar issue with the mii interface on a custom board based on stm32f429. I copied over and edited the board files rom nucelo_f429zi but am constantly getting the HAL_ETH_Init timed out error. I have cross checked pin connections and alternate functions and the board filed etc and don't have any other ideas forward. I made a post about this on slack here. Is there any other way to get further help on this?