# 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:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![pblase](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/pblase/32/2015_2.png) [@pblase](https://forums.freertos.org/u/pblase)\
**Post date:** [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/1 "2021-04-30T19:01:49Z")

</div>

Writing a program for the ATSAMC21E18A, using Microchip Studio, FreeRTOS 10.  
One of my tasks, which is very similar to another, which is not misbehaving, is throwing an error that I cannot explain.

The task is continuously cycling, checking a queue for a command to execute. It receives the command and is working its way through, and gets to one

```
case FPGA_HandlerState_t::operating : //FPGA is working
  if (GlobalFlags.FPGA_Handler_RxQueue_Handle != NULL) { //safety
    if (xQueueReceive(GlobalFlags.FPGA_Handler_RxQueue_Handle, (void *)(&IncomingMessage), portMAX_DELAY) == pdPASS) { //returns errQUEUE_EMPTY if timeout and nothing on queue
      //command interpreter
      switch (IncomingMessage.Command) {
      case FPGA_Interface_Commands::reset :
        task_this_p->FH_resetFPGA(task_this_p);
        break;
      case FPGA_Interface_Commands::getmode :
        task_this_p->FH_getmode(task_this_p); <======
        break;

```

Ok, no problem. For some reason, whenever it gets to this call the RTOS does a context switch, The next thing that I know it ends up at the “Dummy\_Handler” routine in startup\_samc21.c “\brief Default interrupt handler for unused IRQs.”. Looking at the call stack it gets there, every time, from vTaskSwitchContext in tasks.c, from line 2667 at the call to taskCHECK\_FOR\_STACK\_OVERFLOW. However it’s not going there from the stack-overflow handler in main.c, which is implemented, and I’ve ended up there before, so I know it works. The stack dump looks ok, the Queues look ok. No clue as to what the thing is complaining about? How do I find what is triggering this?

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

---

<div class="post-metadata">

**Author:** ![pblase](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/pblase/32/2015_2.png) [@pblase](https://forums.freertos.org/u/pblase)\
**Post date:** [April 30, 2021, 7:29pm UTC](https://forums.freertos.org/t/at-wits-end-going-to-unhandled-irq-handler-from-vtaskswitchcontext-for-no-apparent-reason/12473/2 "2021-04-30T19:29:07Z")

</div>

further data. I traced the failure down to this point:

```auto
BaseType_t FPGA_Handler_task::send8Data_to_user(uint8_t *data_p, uint8_t count)
{
  BaseType_t retval = pdPASS;
  char dataString[16];
  
  //get semaphore
  xSemaphoreTake(GlobalFlags.UserInterface_TxQueue_Semaphore_Handle, 100);
  
  for (int i = 0; i < count; i++) {
    sprintf(dataString, "%#.2x ", data_p[i]);
    
    char *cp = dataString;
    for (size_t i = 0; i < strlen(dataString); i++) { //do not include terminal NULL, do not trigger addition of CRLF and CURSOR
      retval = xQueueSendToBack(GlobalFlags.UserInterface_TxQueue_Handle, (const void *)(cp+i), pdMS_TO_TICKS(100));
      if (retval != pdPASS) {
        
        //release semaphore
        xSemaphoreGive(GlobalFlags.UserInterface_TxQueue_Semaphore_Handle);
        
        return retval;
      }
    } //end for
  } //end for

```

FPGA\_Handler\_task is sending a response back to the UserInterface queue for transmission through the USART. The queue has 64 elements, this message is only 5 characters long, so I’m not overflowing the queue. If fails on the last character.

The weird thing is that it fails in different places depending on where I have the breakpoints. Sometimes it fails at the final return, sometimes at the xSemaphoreGive statement.

 ![image](https://d2v6vdsk2p900z.cloudfront.net/original/2X/f/f026d5a1faced42c8a8deb0ee404b368332a850b.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:** [April 30, 2021, 7:30pm UTC](https://forums.freertos.org/t/at-wits-end-going-to-unhandled-irq-handler-from-vtaskswitchcontext-for-no-apparent-reason/12473/3 "2021-04-30T19:30:57Z")

</div>

Did you check if it is an unhandled interrupt ? I think NVIC ISPR register contains the currently pending IRQs.  
If there was no matching IRQ it’s probably a stack overflow or another memory corruption. Stack overflow checking even at level 2 can’t catch ALL overflows.

---

<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:** [April 30, 2021, 7:35pm UTC](https://forums.freertos.org/t/at-wits-end-going-to-unhandled-irq-handler-from-vtaskswitchcontext-for-no-apparent-reason/12473/4 "2021-04-30T19:35:47Z")

</div>

> [@pblase](#):
>
> `xSemaphoreTake(GlobalFlags.UserInterface_TxQueue_Semaphore_Handle, 100);`

You should handle a possible timeout properly and maybe not just proceed without owning the semaphore.

---

<div class="post-metadata">

**Author:** ![pblase](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/pblase/32/2015_2.png) [@pblase](https://forums.freertos.org/u/pblase)\
**Post date:** [April 30, 2021, 7:42pm UTC](https://forums.freertos.org/t/at-wits-end-going-to-unhandled-irq-handler-from-vtaskswitchcontext-for-no-apparent-reason/12473/5 "2021-04-30T19:42:06Z")

</div>

Yes, just noticed that. Will fix, but that’s not the problem.

---

<div class="post-metadata">

**Author:** ![pblase](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/pblase/32/2015_2.png) [@pblase](https://forums.freertos.org/u/pblase)\
**Post date:** [April 30, 2021, 7:42pm UTC](https://forums.freertos.org/t/at-wits-end-going-to-unhandled-irq-handler-from-vtaskswitchcontext-for-no-apparent-reason/12473/6 "2021-04-30T19:42:51Z")

</div>

How do I look at that register? It’s not in the IO or the Processor debugger window.

---

<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:** [April 30, 2021, 7:45pm UTC](https://forums.freertos.org/t/at-wits-end-going-to-unhandled-irq-handler-from-vtaskswitchcontext-for-no-apparent-reason/12473/7 "2021-04-30T19:45:34Z")

</div>

Usually it’s possible to display the peripheral registers and also those of the NVIC (interrupt controller) in the debugger. Atmel Studio (?) supports that as far as I remember.  
Also if you have some memory left to waste, try to increase the stack.  
With such weird crashes a stack or (sprintf) buffer overflow is my 1st guess.  
BTW I’m always using snprintf or something similar to avoid string buffer overflows.

---

<div class="post-metadata">

**Author:** ![pblase](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/pblase/32/2015_2.png) [@pblase](https://forums.freertos.org/u/pblase)\
**Post date:** [April 30, 2021, 7:49pm UTC](https://forums.freertos.org/t/at-wits-end-going-to-unhandled-irq-handler-from-vtaskswitchcontext-for-no-apparent-reason/12473/8 "2021-04-30T19:49:29Z")

</div>

![image](https://d2v6vdsk2p900z.cloudfront.net/original/2X/4/44610c9916ad90ad8a4d3d7ebe4adef3d65fff6a.png)  
I can see it but I’m not sure how to interpret it.

---

<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:** [April 30, 2021, 7:53pm UTC](https://forums.freertos.org/t/at-wits-end-going-to-unhandled-irq-handler-from-vtaskswitchcontext-for-no-apparent-reason/12473/9 "2021-04-30T19:53:36Z")

</div>

If ISPR is 0x0 I think there is no interrupt pending and ending up in the unhandled interrupt dummy\_handler is the result of something else.  
Do you catch the fatal exceptions like HardFaults etc. by dedicated handlers ?

---

<div class="post-metadata">

**Author:** ![pblase](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/pblase/32/2015_2.png) [@pblase](https://forums.freertos.org/u/pblase)\
**Post date:** [April 30, 2021, 7:57pm UTC](https://forums.freertos.org/t/at-wits-end-going-to-unhandled-irq-handler-from-vtaskswitchcontext-for-no-apparent-reason/12473/10 "2021-04-30T19:57:06Z")

</div>

No, I’m only catching the FreeRTOS stuff like the stack overflow.

---

<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:** [April 30, 2021, 8:04pm UTC](https://forums.freertos.org/t/at-wits-end-going-to-unhandled-irq-handler-from-vtaskswitchcontext-for-no-apparent-reason/12473/11 "2021-04-30T20:04:01Z")

</div>

I’d propose to add exception handlers for the few processor exceptions, too.  
For development ending up in a forever loop like the standard FreeRTOS asserts/failed hooks. That’s often useful to narrow down weird crashes. Unfortunately those processor exception handlers like normal interrupt handlers have no call stack to backtrace …

---

<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:** [April 30, 2021, 8:04pm UTC](https://forums.freertos.org/t/at-wits-end-going-to-unhandled-irq-handler-from-vtaskswitchcontext-for-no-apparent-reason/12473/12 "2021-04-30T20:04:19Z")

</div>

There is a little info on how to determine which exception handler is executing here: [https://www.freertos.org/Debugging-Hard-Faults-On-Cortex-M-Microcontrollers.html](https://www.freertos.org/Debugging-Hard-Faults-On-Cortex-M-Microcontrollers.html)

---

<div class="post-metadata">

**Author:** ![pblase](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/pblase/32/2015_2.png) [@pblase](https://forums.freertos.org/u/pblase)\
**Post date:** [April 30, 2021, 8:13pm UTC](https://forums.freertos.org/t/at-wits-end-going-to-unhandled-irq-handler-from-vtaskswitchcontext-for-no-apparent-reason/12473/13 "2021-04-30T20:13:12Z")

</div>

Thanks much. I’m going to have to do some coding here.

---

<div class="post-metadata">

**Author:** ![pblase](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/pblase/32/2015_2.png) [@pblase](https://forums.freertos.org/u/pblase)\
**Post date:** [May 3, 2021, 5:07pm UTC](https://forums.freertos.org/t/at-wits-end-going-to-unhandled-irq-handler-from-vtaskswitchcontext-for-no-apparent-reason/12473/14 "2021-05-03T17:07:32Z")

</div>

It’s ending up in the HardFault handler. Any suggestions on how to figure out what’s causing it?

---

<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:** [May 3, 2021, 5:19pm UTC](https://forums.freertos.org/t/at-wits-end-going-to-unhandled-irq-handler-from-vtaskswitchcontext-for-no-apparent-reason/12473/15 "2021-05-03T17:19:05Z")

</div>

See the link Richard posted before for some useful hints.  
Can you single step through the code with a debugger until it hardfaults ?

---

<div class="post-metadata">

**Author:** ![pblase](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/pblase/32/2015_2.png) [@pblase](https://forums.freertos.org/u/pblase)\
**Post date:** [May 3, 2021, 5:19pm UTC](https://forums.freertos.org/t/at-wits-end-going-to-unhandled-irq-handler-from-vtaskswitchcontext-for-no-apparent-reason/12473/16 "2021-05-03T17:19:38Z")

</div>

It’s ending up in the HardFault handler. Any suggestions on how to figure out what’s causing it?  
The assembly code given in the link doesn’t work on an M0 core.

---

<div class="post-metadata">

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

</div>

The fault handler assembly code doesn’t compile for an M0 core. I’ll try single-stepping through the code, the problem is that it’s running multiple tasks so I’m having a hard time figuring out where the fault is.

 ![image](https://d2v6vdsk2p900z.cloudfront.net/original/2X/d/d9634e63821fab4d59ea9fa98f7456e9ff864cd1.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:** [May 3, 2021, 5:32pm UTC](https://forums.freertos.org/t/at-wits-end-going-to-unhandled-irq-handler-from-vtaskswitchcontext-for-no-apparent-reason/12473/18 "2021-05-03T17:32:10Z")

</div>

Single stepping code should be possible regardless how many other tasks are running. Or is the faulty code executed by multiple tasks simultaneously ?

Seems that the example code is for Cortex-M3 and higher and is not supported by Cortex-M0.

**Edit** : It’s documented on [Debugging and diagnosing hard faults on ARM Cortex-M CPUs](https://www.freertos.org/Debugging-Hard-Faults-On-Cortex-M-Microcontrollers.html) that it’s related to _ARM Cortex-M3 and ARM Cortex-M4 microcontrollers_

Google ‘hardfault cortex-m0’ provided these hopefully useful links:

> **[Debugging hard faults in ARM Cortex-M0 based SoCs - Embedded.com](https://www.embedded.com/debugging-hard-faults-in-arm-cortex-m0-based-socs/)**
>
> Programmable system-on-chip (PSoC) architectures such as the Cypress PSoC family of MCUs integrate a wide range of capabilities, including MCU cores like

[https://community.arm.com/developer/ip-products/system/f/embedded-forum/3257/debugging-a-cortex-m0-hard-fault](https://community.arm.com/developer/ip-products/system/f/embedded-forum/3257/debugging-a-cortex-m0-hard-fault)

---

<div class="post-metadata">

**Author:** ![pblase](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/pblase/32/2015_2.png) [@pblase](https://forums.freertos.org/u/pblase)\
**Post date:** [May 3, 2021, 5:53pm UTC](https://forums.freertos.org/t/at-wits-end-going-to-unhandled-irq-handler-from-vtaskswitchcontext-for-no-apparent-reason/12473/19 "2021-05-03T17:53:09Z")

</div>

Thanks much. I’m new to ARM interrupt handling. Quite a bit of a step up from AVR’s.  
Just out of curiousity, the FreeRTOSConfig.h has  
configMAX\_PRIORITIES = 5  
but the M0 only uses 3 interrupt priority levels (2 bits). Is this FreeRTOS priority the same as the processor priority? Should I set this to 3?

---

<div class="post-metadata">

**Author:** ![pblase](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/pblase/32/2015_2.png) [@pblase](https://forums.freertos.org/u/pblase)\
**Post date:** [May 3, 2021, 6:24pm UTC](https://forums.freertos.org/t/at-wits-end-going-to-unhandled-irq-handler-from-vtaskswitchcontext-for-no-apparent-reason/12473/20 "2021-05-03T18:24:50Z")

</div>

Found it! It was an indexing problem in a loop. Thanks much, all.

[Next page](https://forums.freertos.org/t/at-wits-end-going-to-unhandled-irq-handler-from-vtaskswitchcontext-for-no-apparent-reason/12473.md?page=2)