Problem in STM32F7 with ethernetif.c provided by STM32CubeIDE 1.7.0

[SURLEAU.Frederic]

Hi,

Context : STM32F777, FreeRTOS, Cmsis V2, LWIP, Sockets, TCP, UDP

Only one task is used to open, listen, poll, accept, send, receive, and close sockets.

Since STM32CubeIDE 1.7.0 and the new version of ethernetif.c, modifying "low_level_output", we have a problem when sending packets of about 400 bytes or more.

In that case, the client will not receive all data.

The old version called HAL_ETH_Transmit_IT, and then waited for the semaphore from HAL_ETH_TxCpltCallback().

The new version calls HAL_ETH_Transmit_IT, and returns immediatly.

The next call will fail, waits for the semaphore, then releases the previous packet, then retries...

It works well for small packets, but fails with bigger ones for unknown reasons...

A modification that work for us, is to move the call to HAL_ETH_ReleaseTxPacket in HAL_ETH_TxCpltCallback.

With this modification, we never fall in HAL_ETH_ERROR_BUSY...

What do you think?

Regards,

Fred.

[STea]

Hello @SURLEAU.Frederic ,

I don't see a particular reason for the newer version of call to fail with bigger packets, but I think that the modification that you did will only maybe impact memory management but not overall functionality.
It would be great if you can send a simple project in which you comment the part that you removed indicating the CubeFirmware version and CubdeIDE version for analysis to make sure there are no potential issues with this modification.
Regards 

[SURLEAU.Frederic]

Attached is the project TestEth

See README.txt

[DVacc.1]

I have the same problem.

[SURLEAU.Frederic]

A small update.
On our current project, we sometimes have heavy output Ethernet traffic.
The solution I mentioned in the TestEth project is not ideal, some packets are lost.
We have successfully reverted to the old version of ethernetif.c, before the update to STM32CubeIDE 1.17.0.
Regards.

[SURLEAU.Frederic]

Hi,

Does anyone have some news about this problem ?

Regards,

Fred.

[STea]

Hello @SURLEAU.Frederic ,

Sorry for the delayed response but FreeRTOS CMSIS V2 is not supported for F7 series and will be removed in upcoming revision of CubeMX refer to this thread for more details.
Regards

[DVacc.1]

Hello, I notice that .stm32f429 has the same problem.

Regards

[SURLEAU.Frederic]

Ok, back to CMSIS V1.

That will take some time...

[SURLEAU.Frederic]

Hi,

Our project has been reverted to CMSIS V1.

STM32CubeIDE has been updated to 1.8.0, with CubeMX 6.14.0.

The network problem has nothing to do with CMSIS version...

To have ethernetif.c  working properly, we use the template "ethernetif_f7.ftl" from CubeMX 6.12.0.

Regards.

PS : New version of TestETH with CMSIS V1 and choice at runtime for V6.12 or V6.14 :

README.txt :

Project TestEth

Open with STM32CubeIDE version 1.18.0
Firmware package : CSTM32Cube FW_F7 V1.17.2

Open TestEth.ioc
Generate code.

Replace
content of .\LWIP\Target\ethernetif.c with ethernetif.template

#############################################################################################

ethernetif.c changes :
2 versions in 1 :
-Version 1 = V_6_12_0
-Version 2 = V_6_14_0

lwipopts.h changes :

- Disable SYS_LIGHTWEIGHT_PROT :
#ifdef DEBUG
// Problems with semaphores with debug
#define SYS_LIGHTWEIGHT_PROT 0
#endif

#############################################################################################

Compile, and flash.

Serial console ( 115200 8-n-1 ) is on UART8 on our board. We do not have dev-board for ST.

Console commands : ( direct commands, no need to enter )

'h' : Help
'R' : REBOOT
'1' : eth_mode = V_6_12_0;
'2' : eth_mode = V_6_14_0;

Choose one eth_mode

Connect Telnet =>

ST mode : Only first message sent.
ARD modes : All messages (100) sent.

Sending data through the telnet client causes 100 messages of 1500 bytes to be sent.

#############################################################################################

The problem with ST version of 'low_level_output()' occurs only with FREERTOS and a number of tasks running.

In the example, if you remove all tasks but mainTask, low_level_output will work fine.

#############################################################################################