2020-02-10 06:51 PM
@Amel NASRI, @ranran, @Piranha, @Harrold, @Pavel A.
V2 of my fixes and improvements to H7_FW V1.5.0/V1.6.0 Ethernet...
Changes include
Find full details and source in the attached zip. V1 was posted to another developer's question. Please post any questions about V2 here.
Solved! Go to Solution.
2020-04-08 09:52 AM
> There is additional task to handle PHY connection (from CubeH7 example)
Which has the flaws described shortly but pretty clearly in "lwIP API related" part of my topic:
2020-04-15 11:22 AM
Keil has its own version of the STM32H7 drivers (current version 2.5.0), including the drivers for Ethernet MAC and PHY. Has anybody checked if they have all the same problems as HAL?
2020-04-15 05:57 PM
I see at https://community.st.com/s/question/0D50X0000BWqXETSQ3/ethernet-complexity you'd mentioned "STM32Cube_FW_H7 1.5.0 does work".
But it doesn't. This page describes FW_H7 1.5.0/1.6.0 bugs and my fixes/improvements to it. I don't use Keil.
2020-04-16 02:40 AM
When I said that it works I just meant it does the simple things described in the readme (because this example in many other releases of STM32Cube_FW_H7 doesn't even ping); I didn't mean it is bug-free.
My question about Keil drivers still remains for those who do use Keil.
2020-04-21 08:35 AM
any same fix on the STM32F7 firmware?
2020-04-21 06:15 PM
>any same fix on the STM32F7 firmware?
Check Piranha's issues list at https://community.st.com/s/question/0D50X0000BOtfhnSQB/how-to-make-ethernet-and-lwip-working-on-stm32, and search Community for posts about STM32F7 Ethernet.
2020-04-22 06:58 AM
Reply form Keil forum:
"Keil STM32H7 DFP pack 2.5.0 (current version) integrates the latest STM32CubeH7 Firmware Package 1.6.0.
There are just a few patches applied on the following files:
Those are minor patches and the original file is kept with the additional extension .original. So it should be easy to see the changes."
2020-06-20 01:31 PM
Hi Alister, and other community members. I’ve tested your code on stm32h745 – speed is awesome (90Mbit/s) in comparison to original HAL. But I’ve noticed, that CPU utilization is rather high during TCP transmission from board (about 50% @ 480Mhz M7 Core.) While during reception is only about 20-25%. Could someone show me direction for digging to get more free CPU time. Or, maybe, I’m doing something wrong?
Thank you in advance.
2020-06-20 06:39 PM
Thanks for the feedback.
I'd only made easy improvements to the ETH driver's transmit code. I'd identified its throughput would be sub-optimal because its implementation is tentative because it doesn't start any descriptors until all its buffers are successfully linked and so it transmits late. But transmit was not a priority for me and, apart from adding the queuing in ethernetif.c, its shape is unchanged.
For transmit's high CPU utilization, are you able to cast fresh eyes over it?
2020-06-21 03:26 AM
>Could someone show me direction for digging to get more free CPU time.
First, without changing any of the ETH driver...
Next, determine where the cycles are being used:
Improving the ETH driver:
@Piranha, can you share any thoughts please?