HAL_ETH_TransmitFrame sometimes return HAL_BUSY

[MathiasZ]

Posted on February 22, 2018 at 10:16

Hi community,

i got a problem by sending udp packets via HAL_ETH_TransmitFrame() on my STM32F107.  Sometimes (every x packets) the function gives HAL_BUSY back. I dont know why and i have no idea how to fix this.

It seems that something is locking the eth handler....

I try to fix this issue since a few days now and would be really happy if anybody can give me a suggestion how to fix this.

Best regards,

Mathias

[Amel NASRI]

Posted on February 23, 2018 at 12:11

Hi

Zviedris.Mathias.002

‌,

As we don't know so much about your hardware, firmware and configuration, I suggest the following:

1. try to use the exampleSTM32Cube_FW_F1_V1.6.0\Projects\STM3210C_EVAL\Applications\LwIP\LwIP_UDP_Echo_Client (orSTM32Cube_FW_F1_V1.6.0\Projects\STM3210C_EVAL\Applications\LwIP\LwIP_UDP_Echo_Server depending on your use-case) to check if you still have same problem or not
2. check the hardware you are using and compare it withSTM3210C_EVAL schematic

-Amel

[MathiasZ]

Posted on February 23, 2018 at 14:01

Hi Amel,

thank you for your response. Iam on a STM32F107 with already working Webserver (Data on SD-card) and CAN Bus to a STM32F105. It figured out, that the error only occours if i have the following situation:

1. Send data via UDP to STM32F107

2. The STM32F107 is sending the data to the STM32F105 (via CAN-BUS)

3. When the operation on the STM32F105 has finished, the uC sends an echo over CAN-BUS to STM32F107

4. In the CAN-RX callback there is a check if the echo is valid

5. If the echo (from the STM32F105) is valid there is a HAL_ETH_TransmitFrame() call within the callback.

Sometimes it works 1000 times in a row and sometimes there´s a 'HAL_BUSY'  what is locking the process so that the HAL_ETH_TransmitFrame() isn't sending anything.

I dont know what is the cause of 'ETH->Lock == HAL_LOCKED' ....