2021-12-21 01:01 AM
Multiple feedbacks reported around Ethernet HAL driver and applications on STM32Cube FW have been acknowledged and analyzed. Many of them were related to RX packets management, to DMA management, or to overall performance. A summary list of tickets on GitHub and forum is provided below for reference.
We apologize for the time it took to provide an adapted solution. We are changing support model to provide more dynamic updates in the future (mainly leveraging GitHub mechanisms).
Today, based on the received feedbacks, the Ethernet HAL driver has been reworked to fix most known issues, enhance performance, and add some missing features.
The reworked Ethernet HAL driver (along with updated applications) is being deployed on STM32CubeH7, STM32CubeF4 and STM32CubeF7 FW packages.
Official publication dates are aligned with maintenance dates: 22Q1 for STM32H7 and STM32F4, and 22Q2 for STM32F7.
Before the official publication: the reworked Ethernet HAL driver and applications are shared on GitHub (https://github.com/STMicroelectronics/stm32h7xx_hal_driver/pull/16) in the form of a pull request, available for everyone for use and review. Feedbacks, comments, enhancements, and proposals are more than welcome.
After the official publication: more frequent updates are planned and will be anticipated on GitHub.
The reworked Ethernet HAL driver brings multiple changes and a compatibility break vs. legacy Ethernet HAL driver. Main changes are listed here:
The new Ethernet HAL driver is supported by STM32CubeMX release of 22Q1 on STM32H7 and STM32F4. Support on STM32F7 follow in 22Q2.
Since the new Ethernet HAL driver brings a compatibility break, existing projects using it shall be updated accordingly. A step-by-step guide for how to update existing projects is shared in this forum and soon in a dedicated Wiki page. A pull request on STM32H7 CubeFW LwIP projects is also provided here to show how modifications are done.
Also, users with existing projects, who don’t want or need to move to the new Ethernet HAL driver can keep their projects running by pointing to legacy driver that will be available in a dedicated folder in future STM32Cube FW packages.
We warmly thank community contributors, and especially @alister and @Piranha who did a great job synthesizing encountered issues and feedbacks. We keep looking for your feedbacks to continue enhancing and adapting for your needs.
General FAQ :
Detailed List of tickets:
Here below a list of main ticket that have been taken into consideration and fixed in the new Ethernet HAL driver and applications. Some of them come from community (very well summarized in a single post), some others are logged on GitHub, and others were logged on internal bug tracking system (the items without hyperlink):
81088 [ETH] RM0433 v6 faults and missing details on ETHERNET related sections
100608 [ETH]: Need to add new fields in the ETH_TxDescListTypeDef
79181 [STM32H7] ETH Ingress correction register
75481 Ticket 75481 - Ethernet PPS functionality clarification
62100 ARPEN support in Ethernet Driver
79615 Ethernet: Enable and handle the DMA
67970 Read Buffer Underflow interrupt
91624 SCB_InvalidateDCache_by_Addr alignment in ethernetif.c
97885 Question about CMSIS EMAC driver
100109 [HAL_ETH] By default MMC interrupt is not handled
83608 LWiP Interrupt and Through Put is Low
81685 [MW_LwIP] Can't ping device with mDNS feature
81312 Length value issue in HAL_ETH_GetReceivedFrame_IT
41452 MBED / Ethernet: inconsistent transmission issue
74243 Add LWIP examples for DISCO-H747I
48259 [ETH] Support of PTP feature in the driver
101731 [LwIP/ETH/MSP][ExamplesMX] Missing initialization to 0 for most local variables of
67276 Several bugs in ethernetif.c: giving back Rx descriptor to DMA before packet was processing by LWIP
91976 LWIP HAL project race condition
91624 SCB_InvalidateDCache_by_Addr alignment in ethernetif.c
108075 Ethernet not working with high AHB/APB2 divider
62100 ARPEN support in Ethernet Driver
67970 Ethernet: Enable and handle the DMA Read Buffer Underflow interrupt
104729 [GitHub] Wrong HSE_VALUE in NUCLEO-H743ZI LwIP_HTTP_Server_Netconn_RTOS application
101385 [ETH] Same issue as ticket 40298 but in STM32CubeH7 v1.8.0
101620 Support of MW_AzureRTOS and associated applications
63844 [LwIP License update] Update the Licenses (in readme and source files)
106013 [ETH] Ping max buffer size
108010 Ethernet HAL workaround against Ping Flood issue
108675 Ethernet erroneous data received in RMII configuration
108674 Ethernet erroneous data received in RMII configuration
108670 Ethernet erroneous data received in RMII configuration
Forum https://community.st.com/s/question/0D50X0000C6eNNSSQ2/bug-fixes-stm32h7-ethernetNetIPAnalysis.docx (including multiple forum tickets)
GitHub https://github.com/STMicroelectronics/cmsis_device_f7/pull/1
GitHub https://github.com/ARMmbed/mbed-os/issues/12459
GitHub https://github.com/STMicroelectronics/stm32h7xx_hal_driver/issues/8
GitHub https://github.com/STMicroelectronics/STM32CubeF4/issues/60
2022-12-09 06:45 AM
"Even one person working on these issues would make more progress than what they are providing now."
Absolutely. ST should provide complete working code packages (like Espressif, which is half the price, and is available).
Rudeness exists on all forums which have no functioning moderators. I run a "tech" forum too and would never allow some of what gets posted here, but if the person in question is one of only two writing more than a few lines, the mod needs to be more restrained otherwise the guy will disappear. I remove around 1 person per year, all extremely rude, but most of them were also good contributors. It is an ego problem really. There is no good solution.
I suspect ST has an arrogant corporate culture, stemming from the French origin which has always produced severe customer service issues (a friend has a job dealing with this, in a French company, and he says it is impossible to fix).
2022-12-09 07:57 PM
Isn't there a code of conduct in this forum? Didn't check....
2022-12-20 07:10 AM
Hi @dradoicic, a quick guide for migration from LwIP to NetDuo is available on wiki page here: https://wiki.st.com/stm32mcu/wiki/Introduction_to_NETXDUO#Migration_to_NetX_Duo
Otherwise, some instructions on how to use NetXDuo APIs in general are provided here: https://wiki.st.com/stm32mcu/wiki/Introduction_to_NETXDUO#How_to_use_NetX_Duo
Please note that starting from X-CUBE-AZRTOS-H7 V3.0.0 and all new series releases coming forward, we've made Azure RTOS MW Stacks initialization easier for you by adding the MW Init feature with STM32CubeMX. (more details on this new feature will be documented soon)
Would that be helpful for you ?
2022-12-20 10:35 AM
Hi @MWB_CHa ,
We are very satisfied with the NetXDuo stack. It's working extremely well even in very harsh environments. On H755 that stack was working even when we injected 2kV directly and RF 10-12V/m... excellent stability. :)
We are preparing it for some tests up to 30V/m... to the extreme. :)
We are looking forward to V3, to check it.
2022-12-20 11:37 AM
Glad to hear that, @dradoicic !
If you are interested by V3.0.0, it's already on line from STM32CubeMX tool and on GitHub: https://github.com/STMicroelectronics/x-cube-azrtos-h7
2023-04-27 02:25 AM
Hi MWB_CHa (ST Employee)
I would like to get some clarification here.
Is the fix only valid (and tested) for IT mode or does it also work in pooling mode (despite performance degradation) too?
Thanks
2023-04-27 03:37 AM
Hi @Community member
The fix is usable and validated in both IT and polling modes, but it is not advised to use polling mode because it will result in degraded performance.
Does it answer your question ?
2023-04-27 05:29 AM
Thank you,
that's what I wanted to hear.
2023-04-27 01:57 PM
Does this code actually work?
All the ST ports of open source modules (e.g. LWIP) need extensive patching, and spending weeks on google looking for fixes and applying them.
In particular, stuff like "Enhance maximum throughput in RX (94Mbs) and TX (92Mbs)" is BS. The only way to get a speed anywhere near that will be a tight loop which is just sending packets and doing nothing else.
2023-04-27 04:35 PM
My network topic is still valid, updated and includes the reworked drivers.
The network performance numbers do include the processing of all of the network layers, but obviously do not include the application processing. They show the network performance - how fast the system can get the network packets to/from the application. What your particular application does with those packets is not an indicator of a network performance. And a full wire speed of 100 Mbps is not only possible, but, for example, on F7 series can be reached with less than 20% of the CPU load. Therefore more than 80% of the CPU time is still free for application processing. I wouldn't call it "nothing else"...