STM32F7: Ethernet deadlock on TxCpltCallback

[Sandro_K]

Hi,

I have a problem with the Ethernet on a STM32F777 with CMSIS V2 and LWIP. Firmware package is 1.17.2.

The configuration was created with CubeMX. The firmware runs normally until a data packet (ping command from cmd) is received on the Ethernet. Then the firmware gets stuck at the semaphore of the TxCpltCallback.
I have attached the call stack as a screenshot.
When the data packet arrives, HAL_ETH_IRQHandler() is called and then the function HAL_ETH_RxCpltCallback(). So far everything works. Then the function HAL_ETH_IRQHandler() is called again and in it the function HAL_ETH_TxCpltCallback(). The firmware then stops at the position of the attached screenshot.

There is already a similarly described case in the forum, but the solutions described there are already implemented in the current F7 firmware package and it still does not work. [ https://community.st.com/t5/stm32cubemx-mcus/bug-stm32-lwip-ethernet-driver-tx-deadlock/td-p/83219 ]

Can someone please help me? Many thanks in advance.

[Pavel A.]

Most likely, the ETH interrupt priority is above configMAX_SYSCALL_INTERRUPT_PRIORITY.

 

[Sandro_K]

The Ethernet Interrupt priority is set to 5 and configMAX_SYSCALL_INTERRUPT_PRIORITY is 5 too.

For tests i changed the Ethernet interrupt priority to 6 but without any success.

[Pavel A.]

Well. Then, if  "firmware gets stuck" means the ConfigASSERT(pxQueue->uxItemSize ==0) triggers: the semaphore struct may get corrupted? And not only the semaphore.

 

[jumman_JHINGA]

Try with CMSIS V1 ... CMSIS V2 has some bugs

[Sandro_K]

It seems that the affected task is the ethernetif_input task. It has a default size of 350. I changed it manually in the tode to 4096.

Although there is no stackoverflow, but the TxPktSemaphore is corrupted. The value of the size parameter in the semaphore structure is invalid.

There must probably be a memory overlap so that the semaphore is overwritten