topic Re: using c++ exceptions with freertos in Kinetis Microcontrollers

using c++ exceptions with freertos

markusklemm — Tue, 13 Sep 2016 10:54:17 GMT

I'm using a ARM Cortex M4 with freertos using freescales freedom Kinetis IDE (gnu arm toolchain). Problem is that

try {
throw std::runtime_error("wut");
} catch (...) {
}
results in a halted CPU and code after the try or (when some is added) in the catch handler is not executed.

I ASSUMED that this results in an SVC interrupt, I'm sorry I got that wrong, Freertos tricked me into this, because when I throw something it halts in DefaultISR.

The throw indeeds jump to **__cxa_throw then from there to ___Unwind_RaiseException __gnu_Unwind_RaiseException __cxa_begin_catch>
<_ZSt9terminatev>**
So it looks like `std::terminate` is called, but the catch all block should not allow this. Or is my assumption wrong and this behavior is because the gcc C++ runtime exception support is a stub which always calls terminate?!

we are using
Kinetis Design Studio 3.2.0. with the
GNU ARM C/C++ Cross Compiler
Version: 1.12.1.201502281154
for our
FRDM-KV31F

Re: using c++ exceptions with freertos

FreeRTOS_org — Tue, 13 Sep 2016 16:42:50 GMT

By fault, most of your exceptions will execute the default handler, so the first thing you need to do is determine which exception is actually executing. You can see the "Determining Which Exception Handler is Executing" section on the following page: http://www.freertos.org/Debugging-Hard-Faults-On-Cortex-M-Microcontrollers.html

I would guess, since you are not using a peripheral in your code, that it will be a fault handler, probably the hard fault. The same page (see link above) gives instructions on debugging that too.

Other than that - ensure you do the normal FreeRTOS debug things, like ensure you have configASSERT() defined, and that you have stack overflow checking on. Info on those topics is found on this page: http://www.freertos.org/FAQHelp.html

Re: using c++ exceptions with freertos

markusklemm — Thu, 15 Sep 2016 13:30:36 GMT

It's the hard fault, since it stops there after throwing after I define an own HardFault_Handler.
My biggest question at the moment is: Is C++ exception handling supposed to work out of the box, with freeRTOS or without an OS?! I'm asking since this is a brown field project I have been thrown into, and if you say "Yeah it should work, so it looks like wrong interrupt management" I know where to look.

Re: using c++ exceptions with freertos

markusklemm — Mon, 19 Sep 2016 15:59:50 GMT

Because I saw that rand() tries to use malloc(), I also defined a working malloc()/freeRTOS function and et voilà: __cxa_allocate_exception uses malloc (I wonder how the toolchain expects me to handle a bad_alloc case).

So now, it still crashes, but after exception allocation (I think):

The excecution path is :

(throwing function after exception allocation)

__cxa_throw

   ... //(some intructions in __cxa_throw)
   __cxa_begin_catch //I guess something went wrong here
    _ZSt9terminatev // Immediately after __cxa_begin_catch
        _ZN10__cxxabiv111__terminateEPFvvE:
         00016dfc: push {r3, lr}
         00016dfe: blx r0 //Goes directly to WDOG_EWM_IRQHandler or hard fault handler
         00016e00: bl 0x194ac <abort>

If you wonder or it might help: My debuggers say its the WDOG_EWM_IRQHandler I crash into, if I not define the hard_fault handler and an own default handler.

So I guess something went wrong in the stack unwinding, because I go thru some symbols with "finished stack unwinding" in the name in _throw, but I didn't catched the break point I set in a destructor of an object which should have been cleaned up. And that seems to motivate __cxa_begin_catch to call abort or something.

Re: using c++ exceptions with freertos

markusklemm — Tue, 03 Jan 2017 13:10:02 GMT

Problem solved : Throw ends in abort on new blank frdm22f project (+ malloc/new )
Remove -specs=nano.specs in the linking options.