# HardFault\_Handler - 2 UART channels **URL:** \ **Category:** Kernel\ **Tags:** debug\ **Created:** [April 11, 2021, 2:54pm UTC](https://forums.freertos.org/t/hardfault-handler-2-uart-channels/12261 "2021-04-11T14:54:49Z")\ **Posts on this page:** 1\ **Showing post:** 2
**Author:** ![hs2](https://avatars.discourse-cdn.com/v4/letter/h/a4c791/32.png) [@hs2](https://forums.freertos.org/u/hs2)\ **Post date:** [April 11, 2021, 5:12pm UTC](https://forums.freertos.org/t/hardfault-handler-2-uart-channels/12261/2 "2021-04-11T17:12:16Z")
Besides defining [configASSERT](https://www.freertos.org/a00110.html?_ga=2.213540052.1971135108.1609110559-800452554.1575115350#configASSERT) you should also enable [stack overflow checking](https://www.freertos.org/Stacks-and-stack-overflow-checking.html) for development/debugging. Using assertions can help to catch a number of HardFaults with the possibility to trace back and identify the problem. Having `configASSERT` defined (in FreeRTOSConfig.h as documented) makes debugging a lot easier by stopping the debugger if the application hangs. If the hang is caused by an assertion, the application is halted in the forever loop usually the last part of the assertion code (as in example 2) and check the _call stack_ for the cause of the assertion. Except fatal application programming bugs the main reasons for application crashes are 1. stack overflows (see above) 2. wrong interrupt priorities for certain ports/MCUs e.g. with Cortex-M CPUs STM32 (which one ?) comes with Cortex-M CPUs and the choosen interrupt priorities have to match `configMAX_SYSCALL_INTERRUPT_PRIORITY` in your `FreeRTOSConfig.h` See [RTOS for ARM Cortex-M](https://www.freertos.org/RTOS-Cortex-M3-M4.html) and mabe also [this](https://forums.freertos.org/t/understanding-priority-levels-of-isr-and-freertos-apis/10453/16) pretty good picture for details. --- _[View the full topic](https://forums.freertos.org/t/hardfault-handler-2-uart-channels/12261)._