Skip to main content
Visitor II
June 25, 2024
Solved

STM32F765 Ethernet

  • June 25, 2024
  • 4 replies
  • 3424 views

I'm trying to get Ethernet working with STM32F765VIH MCU and developing using Keil MicroVision and CubeMX 6.11.1

When setting up CubeMX I'm seeing warning message that RAM needs to point to 0x24000000 for ethernet to work.
I don't see an option for setting ETH RX Buffer Address like in previous versions of CubeMX. Has this been renamed or moved somewhere else.

    This topic has been closed for replies.
    Best answer by mƎALLEm

    Issue of RAM (the warning message related to 0x24000000 address) is fixed in v6.13.0.

    4 replies

    Technical Moderator
    June 25, 2024

    Hello @lb2 and welcome to the community.

    There is no RAM location at address 0x24000000 for STM32F7. I think you're using a project from STM32H7 (AXI-SRAM located at 0x24000000).

    STM32F76xx (from AN4667) :

    SofLit_0-1719307103004.png

    STM32H74x/STM32H75x (from AN4891) :

    SofLit_1-1719307245995.png

     

    lb2Author
    Visitor II
    June 25, 2024

    It is a STM32F765VIH6 device on the board and I started this project from scratch. What I'm seeing is a warning.

    Do I need to set something else for this warning to go away or should be ignored. PHY drivers have been selected in LwIP.

    lb2_0-1719357648447.png

     

    Technical Moderator
    June 26, 2024

    Try to ignore it.

    Could you please attach your ioc file?

    Technical Moderator
    June 28, 2024

    Hello and thank you for the sharing.

    To me the warning message is wrong as there is no RAM at the address 0x24000000 for F7 products (internal Ticket 185332)

    Doing a search inn all the generated projet I didn't find any address pointing to 0x24xx xxxx. So, I think the warning is just a message.

    Regarding "ethernetif_input() *p is always null." hope my colleague @STea  can help you. 

    ST Employee
    June 28, 2024

    Hello @lb2 ,

    Can you please send your schematics to make sure that you are assigning the right pins as configured in MX.

    could you please get the status of PHY after init and check the status of DMAs as well.
    As a suggestion you can try to have the same Ethernetif.c file found in STM32CubeF7/Projects/STM32F767ZI-Nucleo/Applications/LwIP/LwIP_HTTP_Server_Netconn_RTOS at master · STMicroelectronics/STM32CubeF7 (github.com).and adapt your pinout configuration to eliminate any software component related issue and start the elimination process form there. 

    Regards

    lb2Author
    Visitor II
    July 15, 2024

    Hello @STea 

    Did not get a chance to work on this for last couple of week and starting again today.

    I cannot send schematics. I have wired up Ethernet in STM in RMII mode to the PHY. I know PHY is working because I have another device wired to it and I can communicate with it at 100Mbps mode. Other device is wired to PHY in MII mode but that should not matter.

    I'm going to follow your link and see if I make any progress.

    Thanks.

    ST Employee
    July 16, 2024

    Hello @lb2 ,

    It is not recommended to have two MCUs communicate with a single PHY (such as the LAN8742) simultaneously using different interfaces (RMII and MII). 

    In fact, the LAN8742 PHY is typically configured to work with either RMII or MII, but not both simultaneously. The configuration is usually set during the initialization phase and is dependent on the hardware design and software configuration. RMII and MII have different clock and timing requirements. RMII typically uses a 50MHz clock, while MII uses a 25MHz clock. Managing these different clock domains simultaneously would be complex and could lead to timing issues. The MDIO/MDC interface is used to configure and manage the PHY. If two MCUs are trying to control the same PHY, there could be conflicts in the configuration and management of the PHY registers. 


    Regards

     

    mƎALLEmAnswer
    Technical Moderator
    November 27, 2024

    Issue of RAM (the warning message related to 0x24000000 address) is fixed in v6.13.0.