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?
Is it possible with MDK ARM save the stack trace in MCU's memory?
No. Nor would it do you much good in there.
You need uVision connected to the target MCU and the application's ELF file loaded to get the call stack unwound and displayed textually. So you already have it on your PC and you can look at it there. There would be nothing to be gained by putting it into the MCU at that point.
The MCU on its own has implied knowledge about the current data and layout of the stack, of course, because the running code has to work with it. But it has no idea what all that means in terms of function names, function arguments, local variables, etc.
To make sense of a stack's state and display it in comprehensible form takes symbolic debug information (that's all the stuff that makes an ELF file so much bigger than the .hex file you make from it). The MCU, pretty much by definition, doesn't have that.
So, I can save stacktrace without symbolic names, but only in hex codes. Firstly I would like to get order of functions calls. It would be nice to obtain addresses of functions. Than they could be found in map file. It is enough at the moment. Tell me please how to unleash stack.
I suppose to have some difficulties if the program will stacked in some exception or IRQ handler.
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.