How to make Ethernet and lwIP working on STM32

[Piranha]

This is an umbrella topic where I will collect the key problems and solutions to finally get networking on STM32 working. The issues formatted as bold are the most critical ones.

HAL ETH drivers have been significantly reworked since the following firmware packages: CubeF4 v1.27.0, CubeF7 v1.17.0, CubeH5 v1.0.0, CubeH7 v1.10.0

Series: F1, F2, F4, F7, H5, H7 (all STM32 with Ethernet)

• lwIP driver Tx deadlock. [reworked drivers]
• Missing compiler and CPU memory barriers. [legacy drivers]
• RMII mode not enabled because of lacking SYSCFG synchronization. [legacy drivers]
• Unwanted interrupts not masked.
• CubeMX generates wrong PHY configuration. [legacy drivers]
• Not possible to use a custom PHY driver in CubeMX. [reworked drivers]
• Wrong clock source and PLL configuration. [examples]
• lwIP driver zero-copy Rx PBUF pool size is inappropriate. [reworked drivers]
• CubeMX generates broken lwippools.h file for C++.
• CubeMX generates a dysfunctional lwIP application without RTOS.
• Unnecessary delay in LAN8742_Init() and link state management in low_level_init(). [reworked drivers]
• Unnecessary delays and peripheral reset in HAL_ETH_Init() function.
• Multiple flaws in a PTP API implementation. [reworked drivers]
• Poorly chosen MDIO frequency limits and scarce documentation.

Series: F1, F2, F4, F7 (older Synopsys basic peripheral)

• Many flaws as a result from incorrect porting of the reworked H7 series HAL ETH driver. [reworked drivers]
• No DMA access to a data in FLASH memory. [reworked drivers]
• Tx complete interrupt not triggered. [legacy drivers] The related documentation is also wrong.
• Wrong Tx checksum offload documentation.
• Wrong PTP clock source documentation.
• Wrong PPS output documentation.

Series: H5, H7 (newer Synopsys QoS peripheral)

• HAL ETH driver sets wrong MDIO frequency.
• Wrong descriptor ring length documentation.
• Wrong and misleading descriptor tail pointer documentation.
• Wrong or scarce DMA Rx resuming documentation.

Series: F7, H7 (Cortex-M7 CPU)

• Flawed MPU configuration and D-cache maintenance in lwIP driver. [reworked drivers]
• Overlapping and merged memory regions in linker script files.
• Critical spelling errors in linker script files.
• The example code in the article "DMA is not working on STM32H7 devices" is flawed in multiple ways.

lwIP API related:

• Ethernet link and DHCP management code is not thread-safe. When used with RTOS, the code ignores lwIP requirements described in Common pitfalls and Multithreading.
• The example code in the article "How to create project for STM32H7 with Ethernet and LwIP stack working" is not thread-safe. It uses RTOS and lwIP RAW API, but doesn't do lwIP core locking.
• Improper use of NETIF and link up/down statuses. The meaning of netif_set_up()/netif_set_down() functions changed in v2.0.0, but ST's code is not updated. Now NETIF must be up regardless of link state, but for a link state only the functions netif_set_link_up()/netif_set_link_down() must be used.
• Improper use of DHCP client. The code is for an outdated version of DHCP client, which needed external state management. Current versions fully manage the state internally. Monitoring of the state and reporting IP addresses can be done by a callback set up with netif_set_status_callback() without wasting a thread on it.

Other related information:

Another detailed topic by @alister​: "[bug fixes] STM32H7 Ethernet". While mostly dedicated to H7 series, it also has a good amount of information relevant to all Ethernet/lwIP related development.

Open source zero-copy Ethernet/lwIP driver example. The hardware driver is for F2 series, which means that it's almost the same for all Fx series. The lwIP related code and general ideas are still valid for all series.

My other closely related topic: "Actually working STM32 Ethernet and lwIP demonstration firmware". As that topic is currently unavailable, because ST still has not moved it to the new forum, I am attaching a PDF copy of that topic and the related firmware files to this topic.

[bully]

Hello,

oh my god... Any update on this matter ? Do we have some working example code with FreeRTOS and LWIP ?

If not which one is closest one ?

I was about to debug code for simple UDP client using Socket API for LwIP, but I guess this is dead end path :-(...

Can I get any better if I use raw API of LwIP or even use LwIP without FreeRTOS ?

I don't have such complex task to do (gateway from UART connection to MQTT-SN server)...

@Mikk Leini​ : I'd be more than happy to read if you are willing to provide some more details about your work with STM32 and MbedOS.

Thanks in advance,

regards,

Rob.

[RZasa.1]

Hi Piranha,

See my last answer in this topic:

https://community.st.com/s/question/0D50X0000BMErkFSQT/stm32f407-lwip-ip-stack-stop-working-during-tcp-port-scanning-from-vulnerabilities-test-tool

In my case code generated by STM32CubeIDE was simply setting not enough stack size for "EthIf" thread.

[JMath.2]

This patch is for V1.6.0, has any of this been merged by ST into 1.7.0?

Thank you for your work.

It's tough to work with a PDF and code snipits. Moving this to a GitHub fork of 1.6.0 would allow all those changes to be tracked and pulled into our code.

[RZasa.1]

I am currently experiencing one of those strange behaviours. LWIP is not able to get IP but when I add one line of code somewhere - even if it is after LWIP initialisation (so totally irrevelant to LWIP operation) LWIP is working again. Problem will come and go as I am developing my application by adding more lines of code. All my threads have enough stack memory allocated but the problem looks like something related to memory. I am not sure how to debug it. I am using NUCLEO-F767ZI

[Parvez Akhtar]

Hi,

I am using CubeF4 v1.27.1 and Olimex P407 board. I wanted to use LwIP_HTTP_Server_Netconn_RTOS example with RMII interface. I have correctly configured all the Pins. I am able to ping the device but the moment web server is being browsed from browser the devices gets stuck in deadlock and ethernet interrupt stops working.

I found interrupt is being stopped due to DMA error

if (__HAL_ETH_DMA_GET_IT(heth, ETH_DMASR_AIS))

 {

  if (__HAL_ETH_DMA_GET_IT_SOURCE(heth, ETH_DMAIER_AISE))

  {

   heth->ErrorCode |= HAL_ETH_ERROR_DMA;

   /* if fatal bus error occurred */

   if (__HAL_ETH_DMA_GET_IT(heth, ETH_DMASR_FBES))

   {

    /* Get DMA error code */

    heth->DMAErrorCode = READ_BIT(heth->Instance->DMASR, (ETH_DMASR_FBES | ETH_DMASR_TPS | ETH_DMASR_RPS));

/********* here interrupt is being disabled from *****/

    /* Disable all interrupts */

    __HAL_ETH_DMA_DISABLE_IT(heth, ETH_DMAIER_NISE | ETH_DMAIER_AISE);

/********

    /* Set HAL state to ERROR */

    heth->gState = HAL_ETH_STATE_ERROR;

   }

Please let me know if this is already fixed. ethernetif.c file is attached.

Regards,

Parvez Akhtar

[Piranha]

This issue is already reported in the following topic. That link is also listed in the main post of this topic and reportedly ST is working on a fix. Also, if you have something else to add, please do it in the linked specific topic, not this one. :smiling_face_with_smiling_eyes:

[Parvez Akhtar]

Thank you Piranha,

I appreciate your response. I got the link now.

Just a small feedback about the link provided in main topic No DMA access to a data in FLASH memory, it talks about DMA access to flash memory, which is an ultimate root cause of the issue. Its definitely helpful for those who know the root cause of the issue (like due to DMA access to flash memory). But people like me normally search for specific issues like HTTP is not working, deadlock, dma error etc.. for a quick solution. I was instead focusing more on "lwIP driver Tx deadlock" which is also a related issue.

Anyway, you have given lot of comments and remarks on various issues related to ethernetif.c driver for STM32F4. that's why I thought to comment here. Thank you again for help. Waiting for proper solution from STM32 in June.

Regrads,

Parvez Akhtar

[NGiar.1]

I'm trying to make it work with RTEMS and the new STM32H7 HALs (v1.11.1). I've set up a project based upon the sample present on the GitHub page, for the Nucleo-H743ZI. 

My lwipops.h options are the ones suggested from ST (I've tried also with a bigger MEM_SIZE):

#define MEM_SIZE (14 * 1024)

/* Relocate the LwIP RAM heap pointer. Place in SRAM3 */
#define LWIP_RAM_HEAP_POINTER (0x30004000)

/* ---------- Pbuf options ---------- */
/* PBUF_POOL_SIZE: the number of buffers in the pbuf pool.
 @ note: used to allocate Tx pbufs only */
#define PBUF_POOL_SIZE 8

/* PBUF_POOL_BUFSIZE: the size of each pbuf in the pbuf pool. */
#define PBUF_POOL_BUFSIZE 1536

/* LWIP_SUPPORT_CUSTOM_PBUF == 1: to pass directly MAC Rx buffers to the stack
 no copy is needed */
#define LWIP_SUPPORT_CUSTOM_PBUF 1

The variables are also where needed in memory:

ETH_DMADescTypeDef DMARxDscrTab[ETH_RX_DESC_CNT] __attribute__((section(".RxDecripSection"))); /* Ethernet Rx DMA Descriptors */
ETH_DMADescTypeDef DMATxDscrTab[ETH_TX_DESC_CNT] __attribute__((section(".TxDecripSection"))); /* Ethernet Tx DMA Descriptors */
LWIP_MEMPOOL_DECLARE(RX_POOL, ETH_RX_BUFFER_CNT, sizeof(RxBuff_t), "Zero-copy RX PBUF pool");
__attribute__((section(".RxArraySection"))) extern u8_t memp_memory_RX_POOL_base[];

.lwip_sec (NOLOAD) : {
 . = ABSOLUTE(0x30040000);
 *(.RxDecripSection) 
 
 . = ABSOLUTE(0x30040200);
 *(.TxDecripSection)
 
 . = ABSOLUTE(0x30040400);
 *(.RxArraySection) 
 } >SRAM_3
 /* Modification end */ 
 /DISCARD/ :
 {
 libc.a ( * )
 libm.a ( * )
 libgcc.a ( * )
 }

The problem is that the program goes into an exception inside the mem_alloc function. The following is a backtrace taken from GDB:

#0 0x08000ff4 in mem_malloc ()
#1 0x08002ab4 in pbuf_alloc ()
#2 0x08009b8e in etharp_raw ()
#3 0x08009c84 in etharp_request_dst ()
#4 0x08009ca8 in etharp_request ()
#5 0x0800625a in netif_issue_reports ()
#6 0x080062e8 in netif_set_link_up ()
#7 0x0800f148 in low_level_init ()
#8 0x0800ef4e in ethernetif_init ()
#9 0x08005e3a in netif_add ()

_ARM_Exception_default (frame=0x2400b958 <_ISR_Stack_area_begin+3992>)

Can anyone help me understand what's wrong with this?

[Blinti]

In STM32F7 (Cortex-M7) my solution is:

• when start configure the FREERTOS, select the CMSIS v1 (in my case v2 freeze, deadlock, I don't know what happening)
• increase default task stack size to 256 words

And that's all, the lwip working reliable, and finally replying the ICMP (ping, echo) packets succesfully.
(In my case is: Nucleo-F756ZG, MCU: STM32F756ZGT6)

Any other config not needed, I mean enable the MPU, enable ICache, DCache, modify the ethernetif.c or lwip library files. So my conclusion is, I think the lwip middlewares not compatible yet the CMSIS v2 FREERTOS.

[lavanya]

Thank You @Blinti  For Your Replay,

Can I know Which version of cube Mx you are using, For me Cube Mx 5.4 version ethernet stack is working but same configuration I tried for cube Mx version 6.8 it's not Working.

[Wai Siang]

I think new users do not have time and expertise to read all these to use a ethernet port.
it is better to classify it by use cases and related issues seen by customers/users. 
for example in your list of topic:
if you face XXX problem, read topic 1,2,3 and 4
if you dont want RTOS, read 5,6,7
if your ping lost, check out 8,9,10