cancel
Showing results for 
Search instead for 
Did you mean: 

LWIP - HAL_ETH_Transmit stall on "Wait for data to be transmitted or timeout occurred"

Mz.1
Associate III

Hi,

I'm using the STM32H743 device.

my main loop sends nonstop UDP messages perfectly.

I decided that I want to add a debug option that when my code has an issue and it stuck in one of the handlers (such as "HardFault_Handler") endless loops, he will send a nonstop special UDP message that indicates that a problem occurred from within the handler endless loop.

I wrote the code, but I see no udp message, when I used the IDE debug option I notice the code is stalling inside the HAL_ETH_Transmit method under the loop "/* Wait for data to be transmitted or timeout occurred */".

any idea why in the main loop the udp messages were sent with no problem and under the Handlers it stalls? do I need to initialize something before sending it?

pls, help!

thank you !!

1 ACCEPTED SOLUTION

Accepted Solutions

Ouch, one of these errors..

Try to use something without interrupts, maybe UART logging.

Or re-write HAL_ETH_Transmit().

I'm actually not the debugging expert, I mostly use UARTs and LEds for that, so maybe someone else has some better ideas.

View solution in original post

6 REPLIES 6
LCE
Principal

That function is using the Systick with HAL_GetTick().

And the Systick is interrupt based and must have a higher priority than from the ISR where it's called from.

Anyway, calling some lwIP TX stuff from some fault handler or ISR sounds "dangerous", to put it mildly.

Mz.1
Associate III

@Community member​ thanks!

do you have a different suggestion on how to implement correctly something similar to notify in case an error occurred?

thank you :)

No problem using that if "some error" occurred, seems kinda elegent.

But with your example as "HardFault_Handler" you should better find the cause for that and simply use IDE debugging why and how you got there.

Mz.1
Associate III

@Community member​ 

true, but I notice that something is wrong with my device firmware only after 72 hours of running.

the code wasn't at the moment on IDE debugging mode so I had no idea what type of handler occurred.

if there was a message that tells me some error event I could have had some idea of where the issue is instead of trying to simulate the bug again for 72 hours on IDE debugging mode.

if implementing something similar to my original idea is not an option then thanks anyway I appreciate the answers.

Ouch, one of these errors..

Try to use something without interrupts, maybe UART logging.

Or re-write HAL_ETH_Transmit().

I'm actually not the debugging expert, I mostly use UARTs and LEds for that, so maybe someone else has some better ideas.

Mz.1
Associate III

@Community member​ great thank you very much :)