<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type="text/xsl" href="https://community.arm.com/utility/feedstylesheets/rss.xsl" media="screen"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:wfw="http://wellformedweb.org/CommentAPI/"><channel><title>Stacktrace into memory</title><link>https://community.arm.com/developer/tools-software/tools/f/keil-forum/33677/stacktrace-into-memory</link><description> 
Keil MDK ARM has cool feature named &amp;quot;Call Stack + Locals&amp;quot;. 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&amp;#39;s memory? 
 </description><dc:language>en-US</dc:language><generator>Telligent Community 10</generator><item><title>RE: Stacktrace into memory</title><link>https://community.arm.com/thread/140931?ContentTypeID=1</link><pubDate>Tue, 02 Feb 2016 13:32:06 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:f01fae53-70b4-45a5-a45e-f164e443394d</guid><dc:creator>HansBernhard Broeker</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;But if the system has access to nonvolatile memory, it can be
an idea to store the registers + stack content&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
As I mentioned before, that idea suffers from the problem that
once you&amp;#39;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.&lt;/p&gt;

&lt;p&gt;
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.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Stacktrace into memory</title><link>https://community.arm.com/thread/137310?ContentTypeID=1</link><pubDate>Mon, 01 Feb 2016 05:44:45 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:6fc3c40b-3bdb-438e-81c8-5ac35ec26f89</guid><dc:creator>edPer Westermark</dc:creator><description>&lt;p&gt;&lt;p&gt;
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.&lt;/p&gt;

&lt;p&gt;
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.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Stacktrace into memory</title><link>https://community.arm.com/thread/129162?ContentTypeID=1</link><pubDate>Mon, 01 Feb 2016 05:05:04 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:da435fb9-0719-4cee-b2a6-809d5e0cc198</guid><dc:creator>Kevin Pollark</dc:creator><description>&lt;p&gt;&lt;p&gt;
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.&lt;/p&gt;

&lt;p&gt;
Easy.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Stacktrace into memory</title><link>https://community.arm.com/thread/117958?ContentTypeID=1</link><pubDate>Mon, 01 Feb 2016 03:35:55 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:c7ddf6cf-ec9d-48bd-bb56-4334600bd3c3</guid><dc:creator>kyb</dc:creator><description>&lt;p&gt;&lt;p&gt;
Here I found few ideas and recommendations&lt;br /&gt;

&lt;a href="http://stackoverflow.com/questions/11325915/call-stack-unwinding-in-arm-cortex-m3"&gt;stackoverflow.com/.../call-stack-unwinding-in-arm-cortex-m3&lt;/a&gt;&lt;br /&gt;

But they are for GCC.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Stacktrace into memory</title><link>https://community.arm.com/thread/108642?ContentTypeID=1</link><pubDate>Sat, 30 Jan 2016 05:20:16 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:d2dae8e6-1154-4c4a-a241-791e9b4fb45a</guid><dc:creator>HansBernhard Broeker</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;It would be nice to obtain addresses of functions.&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
In theory, yes. In practice, you can&amp;#39;t do it. The MCU just doesn&amp;#39;t
have that kind of overview about its own workings at run time. This
really has to be done off-board, in the debugger.&lt;/p&gt;

&lt;p&gt;
The only thing the MCU could do on its own would be to write a
snapshot of the stack&amp;#39;s state to non-volatile storage of some kind.
I.e. it could try to perform a rough equivalent of the &amp;quot;core dump&amp;quot;
saved by traditional Unix-type OSes. But that raises the next bag
hairy problems: 0) you can&amp;#39;t afford to do this continuously, but 1)
there&amp;#39;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.&lt;/p&gt;

&lt;p&gt;
Ovrall you&amp;#39;re almost certainly trying to go at your actual problem
from the wrong direction. Instead of adding another, complex
mechanism to trigger once there&amp;#39;s something wrong with your stack,
you had better make sure it doesn&amp;#39;t get into a state bad enough to
need that.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Stacktrace into memory</title><link>https://community.arm.com/thread/83021?ContentTypeID=1</link><pubDate>Sat, 30 Jan 2016 03:49:08 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:f51fced3-f687-4491-bfe0-164fdac8c553</guid><dc:creator>kyb</dc:creator><description>&lt;p&gt;&lt;p&gt;
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.&lt;br /&gt;
Tell me please how to unleash stack.&lt;/p&gt;

&lt;p&gt;
I suppose to have some difficulties if the program will stacked in
some exception or IRQ handler.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Stacktrace into memory</title><link>https://community.arm.com/thread/64464?ContentTypeID=1</link><pubDate>Fri, 29 Jan 2016 13:25:28 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:42f5eb37-8838-4741-9b28-aee33616b41d</guid><dc:creator>HansBernhard Broeker</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;Is it possible with MDK ARM save the stack trace in MCU&amp;#39;s
memory?&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
No. Nor would it do you much good in there.&lt;/p&gt;

&lt;p&gt;
You need uVision connected to the target MCU and the application&amp;#39;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.&lt;/p&gt;

&lt;p&gt;
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.&lt;/p&gt;

&lt;p&gt;
To make sense of a stack&amp;#39;s state and display it in comprehensible
form takes symbolic debug information (that&amp;#39;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&amp;#39;t have that.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>