[bug fixes] STM32H7 Ethernet

[alister]

@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

• Decoupling receive buffers from receive descriptors so buffers may be held any length time without choking receive.
• Optionally queuing transmit, so transmit doesn't need to block until complete.
• Many bug fixes.

Find full details and source in the attached zip. V1 was posted to another developer's question. Please post any questions about V2 here.

[elmood]

I’ve tried posting new threads in the past and never get replies.

After inspecting your code and trying to understand how to port to F7 or F4 I can across some lwip docs where they recommend a very simple zero copy pseudo code.

Also it seems like the stock HAL drivers use user supplied buffers for TX and RX so why is it necessary to even modify the HAL driver at all? Wouldn’t it be possible to just make the DMA buffers also useable by LwIP as pbufs? I’d like a solution that is more portable but after comparing the HAL changes against the stock H7 code I’m lost, and there is no hope for me to port this stuff to other chips. I’m very good designing my own code but not good at reversing other people’s work. :(

At this point I’m looking for other IP stack recommendations if anyone has any... honestly I just want to work on my actual application code.

[alister]

Hi elmood

>I’ve tried posting new threads in the past and never get replies.

You should post again. Search for a thread matching your problem and post there, or start a new one if there isn't one. Mention your device (STM32F7), the board you're using if it's a dev board, the software you're using, e.g. Cube version, its F7 FW version, what you're observing not working correctly. Have a good read of the community first, find a few posts that have received good support and try to include the same type of details as those. I've just tried to search STM32F7 and the search looks broken. But if you Google "STM32F7 ethernet problem" you'll get lots of hits. Read those and you'll likely be lucky and find exactly what you need.

>Wouldn’t it be possible to just make the DMA buffers also useable by LwIP as pbufs?

There are countless other ways and doubtless better ways.

The answer to that is a question: can you dimension the rx DMA descriptors large enough for the task that holds a buffer the longest time before freeing without the peripheral throwing a receive buffers unavailable error?

My implementation decouples the rx buffers from the rx DMA descriptors. It's academic now.

The HAL driver changes are because the more code I read the more problems I found.

And having changed the rx buffer queuing, it would be silly for the driver API to use an intermediate queue, so I moved my queue into the driver. Changing an API, even to improve it, is thorny. But thankfully it doesn't matter to customers using ethernetif.c because they don't use the HAL ethernet driver API directly, they use ethernetif.c.

>I’m looking for other IP stack recommendations if anyone has any...

lwIP is almost certainly not the problem here.

[JLakn]

Hey, @alister​ 

I'm working on a custom board project and I'm still in the prototype phase. On board I have a 7" display, ethernet, sd-card,RS485, RS232 and other peripherals. Recently I switched from STM32F767 mcu to fully pin compatible STM32H753. On the F7 project I  implemented VNC server. So when porting the project from F7 to H7 I issued very strange behaviours with ethernet (VNC server disconnecting randomly). Until I found your fix I lost one week of debugging and looking for a bug in my code. So now that I patched drivers following your fix everything works like never before. Many thanks to you for sharing the fix. But I'm wondering why STs HAL team is not doing anything to fix that issue.  You documented all the fixes well and shared all the code. So If I can patch that in one hour why can't they fix it in 9 months. @Amel NASRI​ ​ I think this needs to be number one priority in next release of drivers !

[Nikita91]

To remove an answer, use the tag (black triangle on the right of the message) and leave a message to the moderator.

[DBurr.1]

I have adapted @alister​'s V2 code to work with the LAN8742A PHY found on the NUCLEO H743ZI2 board and made a few minor changes to make it easier to integrate with projects created using STM32CubeIDE.  My modified code (along with instructions on how to integrate it into an existing STM32CubeIDE project) can be found here on github: https://github.com/dgburr/H743ZI2-ethernet

I hope that proves useful to somebody out there.  Thanks to @alister ​for your great work!

[Nikita91]

Thank you very much !!!!

[DBurr.1]

If you follow my instructions, STM32CubeIDE will include the following line in lwipopts.h:

#define ETH_RX_BUFFER_SIZE 1024

I have updated my instructions to make this more clear.

[DSpas.2]

Greetings to all strugling with Ethernet!

PLEASE teak a quick peak at the topic posted here:

https://community.st.com/s/question/0D53W00000S8YnYSAV/semaphore-hang-when-trying-to-send-data-bigger-than-one-tcp-frame

and try to identify the type of the bug we are experiencing. If someone has any idea please give a suggestion as we are desperate to make our product work, but failing to so for several months now.

On the other hand, If there is any expert in this field who is willing to guide us in solving this problem we are willing to donate and/or pay for the time spent on this piece of code we are trying to fix. Just drop me a mail to:

spasovski.dejan@gmail.com

Its scarry how stuck we are with a problem of sending few kilobytes through Ethernet in the 21st century in the tme of communications, where this should be long time closed issue by ST firmware developers. Shame ST MCUs are well built, but the libraries generated by cube are making it nightmare to work with.

Instead of focusing on our application development we are stuck for months solving bugs and concepts from the maker of the chip for something that these days sould be no brainer to implement and shoul take no time to drop into a project.

We have spent a lot of money on our custom hardware and we are stuck with this MCU, but eventually if this goes on furher we would need to select another platform and sadly say goodbye ST.

I hope some good fellow will show up to enlighten us.

Thanksnin advance!

Regards

Dejan

[alister]

This thread describes a modified working Ethernet driver for the STM32H7.

The thread you've linked says you're using STMCubeID generated code. So that wouldn't be this Ethernet driver.

I'm posting a reply to your thread (sorry I've no quick answer).

Unless someone seeing this knows the fix and it's to do with the modified driver of this thread, please move this discussion to Dejan's thread.

Regards

Alister

[DPark.6]

I've been also struggling similar problem quite long time. My problem is that network service (ex. ping/udp) suddenly stop about 3 or 5 mins after started. (The traffic is bigger the time is shorter.)

I've tested the bug-fixed files but failed. today I tried as below.

** Make low_level_output and low_level_input no running concurrently **

ethernetif.c (not bug-fixed, from generated one by Cube)

/* USER CODE BEGIN 3 */

SemaphoreHandle_t eth_sem;

/* USER CODE END 3 */ 

static void low_level_init(struct netif *netif)

{

// original code

/* USER CODE BEGIN OS_THREAD_DEF_CREATE_CMSIS_RTOS_V1 */

 vSemaphoreCreateBinary(eth_sem);

 osThreadDef(EthIf, ethernetif_input, osPriorityRealtime, 0, INTERFACE_THREAD_STACK_SIZE);

 osThreadCreate (osThread(EthIf), netif);

/* USER CODE END OS_THREAD_DEF_CREATE_CMSIS_RTOS_V1 */

// original code

}

static err_t low_level_output(struct netif *netif, struct pbuf *p)

{

  xSemaphoreTake(eth_sem, pdMS_TO_TICKS(1));

// original code

 xSemaphoreGive(eth_sem);

 return errval;

}

static struct pbuf * low_level_input(struct netif *netif)

{

  xSemaphoreTake(eth_sem, pdMS_TO_TICKS(1));

// original code

 xSemaphoreGive(eth_sem);

 return p;

}

Even if it's not  fundamental solution, the result is quite good(stopping doesn't occur anymore) for me and performance also not bad.