Keil MDK ARM has cool feature named "Call Stack + Locals". While debugging in this windows we can see order of functions call (stacktrace) and local variables. Is it possible with MDK ARM save the stack trace in MCU's memory?
It would be nice to obtain addresses of functions.
In theory, yes. In practice, you can't do it. The MCU just doesn't have that kind of overview about its own workings at run time. This really has to be done off-board, in the debugger.
The only thing the MCU could do on its own would be to write a snapshot of the stack's state to non-volatile storage of some kind. I.e. it could try to perform a rough equivalent of the "core dump" saved by traditional Unix-type OSes. But that raises the next bag hairy problems: 0) you can't afford to do this continuously, but 1) there's not really a good way to find out when the important moment has come to make this snapshot, and 2) in that moment, the system will most likely already be in such a bad overall state that saving the snapshot is no longer safely possible.
Ovrall you're almost certainly trying to go at your actual problem from the wrong direction. Instead of adding another, complex mechanism to trigger once there's something wrong with your stack, you had better make sure it doesn't get into a state bad enough to need that.
Here I found few ideas and recommendations stackoverflow.com/.../call-stack-unwinding-in-arm-cortex-m3 But they are for GCC.
Why not download all the source code, object files and map file into the mcu. when an error occurs, look up the address of the failure in the map file, find the function that triggered it and then have the error trap in the mcu send an email to your server with all relevant information. Including the source code line.
Easy.
I have seen systems where the program sends in firmware version, the stack content and all registers, and the server then cross-correlates with map file data for the specific build and produces an annotated report.
But best is to have few enough errors that there is no need for a heavily automated system for analyzing the stack content. But if the system has access to nonvolatile memory, it can be an idea to store the registers + stack content allowing the failure state data to be retrieved if needed.
But if the system has access to nonvolatile memory, it can be an idea to store the registers + stack content
As I mentioned before, that idea suffers from the problem that once you're in such a dire situation that performing this core dump turns into a good idea, the system is most likely no longer able to do this, nor send the crash dump over some communication link.
Now you might think you can get around this problem by setting the stack reserve threshold for triggering the core-dump so high that the dump itself will always work. Unfortunately that means you have to dump core in quite a few situations when this would not otherwise have been necessary. I.e. this approach would make worse the disease it was supposed to help diagnose.