# At wits end - going to unhandled-IRQ handler from vTaskSwitchContext for no apparent reason

**URL:** <https://forums.freertos.org/t/at-wits-end-going-to-unhandled-irq-handler-from-vtaskswitchcontext-for-no-apparent-reason/12473>\
**Category:** Kernel\
**Created:** [April 30, 2021, 7:01pm UTC](https://forums.freertos.org/t/at-wits-end-going-to-unhandled-irq-handler-from-vtaskswitchcontext-for-no-apparent-reason/12473 "2021-04-30T19:01:49Z")\
**Posts on this page:** 1\
**Showing post:** 28

<div class="post-metadata">

**Author:** ![RAc](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/rac/32/1389_2.png) [@RAc](https://forums.freertos.org/u/RAc)\
**Post date:** [May 3, 2021, 8:06pm UTC](https://forums.freertos.org/t/at-wits-end-going-to-unhandled-irq-handler-from-vtaskswitchcontext-for-no-apparent-reason/12473/28 "2021-05-03T20:06:31Z")

</div>

we discussed this before:

> [@Cortex M4 hard fault finding root cause on LPC4078](https://forums.freertos.org/t/cortex-m4-hard-fault-finding-root-cause-on-lpc4078/11944/14):
>
> Unfortunately, that technique doesn’t work reliably for the same reason that the built-in stack overflow cxheck doesn’t work reliably. Assume the stack is close to its end, and the caller task calls a function that does something like that: SomeFn() { unsigned char aBuf[20]; .... } That function while executing may not touch all of the 20 bytes it set aside. Also, you don’t need a static task; you can program the DWT on the fly with any dynamically determined trigger address at runti…

---

_[View the full topic](https://forums.freertos.org/t/at-wits-end-going-to-unhandled-irq-handler-from-vtaskswitchcontext-for-no-apparent-reason/12473)._