Just for the sake of it I found some time to try and get it to work. TLDR: It doesn't
What already worked before, is try/catch exceptions thrown deeper in the callstack without having any code running in ITC memory.
In order to use try/catch with code running in ITC, first I needed to tackle the distance problem. I managed to extract the code that runs in ITC into a separate library and compile that library with the flag -fno-exceptions.
Then I linked library to the rest of my application, while the rest of the app is compiled without -fno-exceptions (and thus uses the default: -fexceptions).
After straightening out some details, I can compile and link my program. It indeed is "flash costly" because my application size (debug build) went from 558392 B to 610756 B (about 50KB of flashed burned, meh ;-)).
But when giving any try/catch block a try where the try would throw, the app hard faulted. I also have a timer running in itc (to get ms precision timers together with the 1sec rtc clock in the cpu). And that also has to run in ITC memory to have them continue while freertos task switches or goes into critical sections e.g.. So something goes wrong, not sure what. Maybe task switches while unwinding the stack results in a hard fault, or more specifically a jump to ITC code is causing the problem, because thats the part which is not compiled with -fexceptions enabled.
This is the stack trace anyway.
I don't know, I guess using exception handling is a bad idea for at least the reasons a) it burns quite a bit of flash, and b) it's rather CPU heavy to unwind the stack, which might even get in the way of the watchdog e.g. The latter was what I was most curious about, just wanted to actually measure how long stack unwinding really took.
But I guess this is a dead end for this application anyway.
If you could be bothered to shared your thoughts, would be appreciated. If you have better things to do too, feel completely free to ignore me :D.
Thx for the insights anyway! It helped a lot.
