# FreeRTOS + TCP is crashing in prvEMACHandlerTask()

**URL:** <https://forums.freertos.org/t/freertos-tcp-is-crashing-in-prvemachandlertask/11487>\
**Category:** Kernel\
**Created:** [January 8, 2021, 6:15am UTC](https://forums.freertos.org/t/freertos-tcp-is-crashing-in-prvemachandlertask/11487 "2021-01-08T06:15:28Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![stshvarts1](https://avatars.discourse-cdn.com/v4/letter/s/3ec8ea/32.png) [@stshvarts1](https://forums.freertos.org/u/stshvarts1)\
**Post date:** [January 8, 2021, 6:15am UTC](https://forums.freertos.org/t/freertos-tcp-is-crashing-in-prvemachandlertask/11487/1 "2021-01-08T06:15:28Z")

</div>

FreeRTOS + TCP project based on STM32F407 is crashing after running for few seconds even without any communication. I was able to trace it to the source:  
prvEMACHandlerTask() \<- ulTaskNotifyTake() in NetworkInterface.c  
and then to taskEXIT\_CRITICAL() in task.c, but what the reason for crashing?

---

<div class="post-metadata">

**Author:** ![rtel](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/rtel/32/31_2.png) [@rtel](https://forums.freertos.org/u/rtel)\
**Post date:** [January 8, 2021, 4:30pm UTC](https://forums.freertos.org/t/freertos-tcp-is-crashing-in-prvemachandlertask/11487/2 "2021-01-08T16:30:33Z")

</div>

Can you please provide more information on how the crash manifests itself. Is it simply hitting an assert(), or overflowing its stack? This page will provide more information on both of those: [https://www.freertos.org/FAQHelp.html](https://www.freertos.org/FAQHelp.html)

---

<div class="post-metadata">

**Author:** ![stshvarts1](https://avatars.discourse-cdn.com/v4/letter/s/3ec8ea/32.png) [@stshvarts1](https://forums.freertos.org/u/stshvarts1)\
**Post date:** [January 8, 2021, 5:17pm UTC](https://forums.freertos.org/t/freertos-tcp-is-crashing-in-prvemachandlertask/11487/3 "2021-01-08T17:17:08Z")

</div>

It jumps to Infinite\_Loop in start\_stm32.s  
I verified configASSERT\_DEFINED is 1

---

<div class="post-metadata">

**Author:** ![hs2](https://avatars.discourse-cdn.com/v4/letter/h/a4c791/32.png) [@hs2](https://forums.freertos.org/u/hs2)\
**Post date:** [January 8, 2021, 5:42pm UTC](https://forums.freertos.org/t/freertos-tcp-is-crashing-in-prvemachandlertask/11487/4 "2021-01-08T17:42:43Z")

</div>

Is the forever loop inside an interrupt handler ? Maybe the `HardFault_Handler` ?  
That should be visible in your debugger. If not check the backtrace/callstack in the debugger.  
Did you setup the configASSERT macro correctly ?

---

<div class="post-metadata">

**Author:** ![stshvarts1](https://avatars.discourse-cdn.com/v4/letter/s/3ec8ea/32.png) [@stshvarts1](https://forums.freertos.org/u/stshvarts1)\
**Post date:** [January 8, 2021, 6:40pm UTC](https://forums.freertos.org/t/freertos-tcp-is-crashing-in-prvemachandlertask/11487/5 "2021-01-08T18:40:08Z")

</div>

I’m running in debugger mode and when crashed it jumped to the Infinite\_Loop of assembly code in start\_stm32.s (line 102) not to HardFault\_Handler.  
configASSERT macro is defined in FreeRTOSConfig.h (line 119)  
Checked all 3 interrupts handlers:  
#define vPortSVCHandler SVC\_Handler  
#define xPortPendSVHandler PendSV\_Handler  
#define xPortSysTickHandler SysTick\_Handler

They all present in …/ARM\_CM4F/port.c

---

<div class="post-metadata">

**Author:** ![hs2](https://avatars.discourse-cdn.com/v4/letter/h/a4c791/32.png) [@hs2](https://forums.freertos.org/u/hs2)\
**Post date:** [January 8, 2021, 6:59pm UTC](https://forums.freertos.org/t/freertos-tcp-is-crashing-in-prvemachandlertask/11487/6 "2021-01-08T18:59:53Z")

</div>

Sorry - only you know your `start_stm32.s` and `FreeRTOSConfig.h` files 😉

> [@stshvarts1](#):
>
> start\_stm32.s (line 102)

Which assembler routine is there ? Or is the CPU executing random stuff/no useful code due to bug/crash ? Do you see a useful callstack in the debugger after stopping the CPU ?

---

<div class="post-metadata">

**Author:** ![stshvarts1](https://avatars.discourse-cdn.com/v4/letter/s/3ec8ea/32.png) [@stshvarts1](https://forums.freertos.org/u/stshvarts1)\
**Post date:** [January 8, 2021, 7:27pm UTC](https://forums.freertos.org/t/freertos-tcp-is-crashing-in-prvemachandlertask/11487/7 "2021-01-08T19:27:55Z")

</div>

In attached screenshot is what is displayed in debugger thread after the crash.

 ![image](https://d2v6vdsk2p900z.cloudfront.net/original/2X/0/0fe74603342be5ebb8f91d90c6228f0485a3528a.png)

---

<div class="post-metadata">

**Author:** ![hs2](https://avatars.discourse-cdn.com/v4/letter/h/a4c791/32.png) [@hs2](https://forums.freertos.org/u/hs2)\
**Post date:** [January 8, 2021, 8:04pm UTC](https://forums.freertos.org/t/freertos-tcp-is-crashing-in-prvemachandlertask/11487/8 "2021-01-08T20:04:49Z")

</div>

So as suspected it’s in an interrupt handler. The Windowed WatchDog IRQ has fired.  
It’s unrelated to FreeRTOS at the first place. What’s the WWDG ISR supposed to do ?  
If unsure just disable the WWDG for now to proceed or find out its timeout configuration and maybe increase it accordingly.  
If this your very 1st try with a FreeRTOS application I’d disable the WWDG at the beginning and verify that your application starts and works as expected.

---

<div class="post-metadata">

**Author:** ![stshvarts1](https://avatars.discourse-cdn.com/v4/letter/s/3ec8ea/32.png) [@stshvarts1](https://forums.freertos.org/u/stshvarts1)\
**Post date:** [January 8, 2021, 8:28pm UTC](https://forums.freertos.org/t/freertos-tcp-is-crashing-in-prvemachandlertask/11487/9 "2021-01-08T20:28:09Z")

</div>

Thanks, will work on it.

---

<div class="post-metadata">

**Author:** ![stshvarts1](https://avatars.discourse-cdn.com/v4/letter/s/3ec8ea/32.png) [@stshvarts1](https://forums.freertos.org/u/stshvarts1)\
**Post date:** [January 8, 2021, 9:32pm UTC](https://forums.freertos.org/t/freertos-tcp-is-crashing-in-prvemachandlertask/11487/10 "2021-01-08T21:32:01Z")

</div>

In the beginning of main() placed WWDG\_DeInit() function, which disables clock for WWDG, but it’s still continuing crashing the same way.

---

<div class="post-metadata">

**Author:** ![hs2](https://avatars.discourse-cdn.com/v4/letter/h/a4c791/32.png) [@hs2](https://forums.freertos.org/u/hs2)\
**Post date:** [January 8, 2021, 9:39pm UTC](https://forums.freertos.org/t/freertos-tcp-is-crashing-in-prvemachandlertask/11487/11 "2021-01-08T21:39:43Z")

</div>

Try power cycle the board. I _think_ the watchdog can’t be disabled once activated. At least it’s the case for the IWDG…  
The WWDG ISR shouldn’t be entered if the WWDG is not activated.

---

<div class="post-metadata">

**Author:** ![stshvarts1](https://avatars.discourse-cdn.com/v4/letter/s/3ec8ea/32.png) [@stshvarts1](https://forums.freertos.org/u/stshvarts1)\
**Post date:** [January 8, 2021, 10:13pm UTC](https://forums.freertos.org/t/freertos-tcp-is-crashing-in-prvemachandlertask/11487/12 "2021-01-08T22:13:32Z")

</div>

Recycled power, disable WWDG by WWDG-\>CR = 0 statement, but still the same. My guess, that there is something else leading to crash.

---

<div class="post-metadata">

**Author:** ![hs2](https://avatars.discourse-cdn.com/v4/letter/h/a4c791/32.png) [@hs2](https://forums.freertos.org/u/hs2)\
**Post date:** [January 8, 2021, 10:35pm UTC](https://forums.freertos.org/t/freertos-tcp-is-crashing-in-prvemachandlertask/11487/13 "2021-01-08T22:35:40Z")

</div>

Hmm … strange. Do you still end up in the WWDG\_IRQHandler even if it’s not enabled ?  
No idea ☹ I afraid it’s on you to narrow down what’s going wrong…  
You should make use of all the FreeRTOS debug features like [stack overflow checking](https://www.freertos.org/Stacks-and-stack-overflow-checking.html) etc.  
Good luck Steven !

---

<div class="post-metadata">

**Author:** ![stshvarts1](https://avatars.discourse-cdn.com/v4/letter/s/3ec8ea/32.png) [@stshvarts1](https://forums.freertos.org/u/stshvarts1)\
**Post date:** [January 8, 2021, 10:41pm UTC](https://forums.freertos.org/t/freertos-tcp-is-crashing-in-prvemachandlertask/11487/14 "2021-01-08T22:41:21Z")

</div>

You’re right it’s on me, thanks for help.

---

<div class="post-metadata">

**Author:** ![richard-damon](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/richard-damon/32/38_2.png) [@richard-damon](https://forums.freertos.org/u/richard-damon)\
**Post date:** [January 9, 2021, 1:07am UTC](https://forums.freertos.org/t/freertos-tcp-is-crashing-in-prvemachandlertask/11487/15 "2021-01-09T01:07:10Z")

</div>

One quick question, is the WWDG\_IRQHandler() a separate ISR, or is this the default vector with all the other undefined interrupt. If the latter, you need to figure out which ISR is actually being triggered.

I find it is often worth the memory cost to make each ISR have its own unimplemented loop so you know which one got triggered.

---

<div class="post-metadata">

**Author:** ![stshvarts1](https://avatars.discourse-cdn.com/v4/letter/s/3ec8ea/32.png) [@stshvarts1](https://forums.freertos.org/u/stshvarts1)\
**Post date:** [January 9, 2021, 5:47am UTC](https://forums.freertos.org/t/freertos-tcp-is-crashing-in-prvemachandlertask/11487/16 "2021-01-09T05:47:05Z")

</div>

> [@richard-damon](#):
>
> WWDG\_IRQHandler

Hi Richard, thanks for responding.  
I didn’t find WWDG\_IRQHandler() function in my project, which, as I hope, has all necessary files. But 3 other ISR, which I mentioned above, are present in port.c and it looks like they all are running, because they respond to break points inside. You are right, I need to figure which event triggers which interrupt. I only know that systick should be triggered by one of the CPU timers.

---

<div class="post-metadata">

**Author:** ![hs2](https://avatars.discourse-cdn.com/v4/letter/h/a4c791/32.png) [@hs2](https://forums.freertos.org/u/hs2)\
**Post date:** [January 9, 2021, 8:42am UTC](https://forums.freertos.org/t/freertos-tcp-is-crashing-in-prvemachandlertask/11487/17 "2021-01-09T08:42:36Z")

</div>

If you’re using ST Cube the file with the `WWDG_IRQHandler` might be part of the generated files. Since the symbol is defined as seen in the debugger call stack there must be the corresponding code somewhere in your project.  
If using Cube is there a provided FreeRTOS demo project (known to work out of the box) helping to get familiar with it ?  
As far as I know there is some documentation or an application note from ST regarding FreeRTOS applications (generated by Cube).

---

<div class="post-metadata">

**Author:** ![richard-damon](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/richard-damon/32/38_2.png) [@richard-damon](https://forums.freertos.org/u/richard-damon)\
**Post date:** [January 9, 2021, 11:33am UTC](https://forums.freertos.org/t/freertos-tcp-is-crashing-in-prvemachandlertask/11487/18 "2021-01-09T11:33:18Z")

</div>

Your stack trace shows the function to be in startup\_stm32.s, which is probably a system provided file. Typically, this file will only have a default entry for each interrupt, to catch interrupts which do not have handlers provided, but which occur. Also, typically there is but one routine which is shared for ALL interrupts as a default. If this is the case here (as I suspect), the fact that it calls it the Watch Dog Interrupt irrelevant, as the debugger doesn’t know which interrupt occurred.

What I will do to these files is change that file so that each interrupt gets its own version of the infinite loop, so when this happens, you can see by which loop it gets caught in, what ISR was triggered. There are also registers in the processor that you can read to figure this out, but that requires digging through the processor documentation and understanding more of the details.

---

<div class="post-metadata">

**Author:** ![htibosch](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/htibosch/32/62_2.png) [@htibosch](https://forums.freertos.org/u/htibosch)\
**Post date:** [January 9, 2021, 12:27pm UTC](https://forums.freertos.org/t/freertos-tcp-is-crashing-in-prvemachandlertask/11487/19 "2021-01-09T12:27:53Z")

</div>

Undefined interrupts will end up in a for ever loop in `Default_Handler`. It is difficult to see which interrupt has occurred.  
When in doubt, you can also include the following file: [stm\_interrupts.c](https://forums.freertos.org/uploads/short-url/rdrokb7QuOhoOC9DLqDYBdp5Vj8.c) (5.0 KB)  
With these defines, you can press pause and see where it is looping for ever.  
You must exclude interrupt definitions that you have already defined. The linker will warn about double definitions…

---

<div class="post-metadata">

**Author:** ![stshvarts1](https://avatars.discourse-cdn.com/v4/letter/s/3ec8ea/32.png) [@stshvarts1](https://forums.freertos.org/u/stshvarts1)\
**Post date:** [January 9, 2021, 9:22pm UTC](https://forums.freertos.org/t/freertos-tcp-is-crashing-in-prvemachandlertask/11487/20 "2021-01-09T21:22:20Z")

</div>

Thanks Hein, it looks like I found the source of crashing, which was enabling ethernet interrupt in HAL\_ETH\_MspInit( ETH\_HandleTypeDef \* heth ) function, which looks like this:  
NVIC\_InitStructure.NVIC\_IRQChannel = ETH\_IRQn;  
NVIC\_InitStructure.NVIC\_IRQChannelPreemptionPriority = 13;  
NVIC\_InitStructure.NVIC\_IRQChannelSubPriority = 0;  
NVIC\_InitStructure.NVIC\_IRQChannelCmd = ENABLE;  
NVIC\_Init(&NVIC\_InitStructure);  
In HAL\_ETH\_MspInit() I also included all GPIO initialization to interface with RMII transceiver chip. I’ve tried to change interrupt priority, but it didn’t help. As long as interrupt is enabled the software crashed.

[Next page](https://forums.freertos.org/t/freertos-tcp-is-crashing-in-prvemachandlertask/11487.md?page=2)
