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.

[JJhin.1]

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

[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.

[Sandro_K]

Yes, you're right. That is the problem.

The size of the semaphore is damaged. The value is overwritten at an unknown code location.

But how can I localize the error? I could not set a memory watchpoint, the function was grayed out.

[Pavel A.]

Similar to this thread?

https://community.st.com/t5/stm32-mcus-embedded-software/stack-overflow-in-freeartos-and-ethernet/td-p/782263

Check task stacks for overrun.

[Sandro_K]

I have debugged again and now I get a stackoverflow error from the task “EthIf”. Where can I increase the stack size and what is a reasonable value? I currently have no application running on the Ethernet and I am already getting the stackoverflow.

[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