Dear Keil MDK-ARM uVision support,
I'm using Keil MDK-ARM uVision 5.14 for ARM Cortex-M3 core, STM32F103 device.
From time to time we get a HardFault exception. We know that if the debugger is connected, it is somehow posible to deduce the offending instruction/routine by opening the Call Stack window and following the hints. That´s fine.
But what about if you get a HardFault and the debugger is not connected? When we get the HardFault, we want somehow to read the same information you are reading for showing the Call Stack window. Our intention is to read the same information you do and send it to a UART port to be able to read it with a Hyperterminal or similar.
We know that reading the stack content is the first step. We are doing it already, but it is not enought for us since in our case the application code is quite complex, and unrolling the stack contents might be complex.
Thanks a lot for your help.
They are more likely to have boiler-plate code that can do something, or specific suggestions.
I think a register dump, and a reasonable depth of stack, should be sufficient in most cases to identify where something failed, and probably why.
Trace hardware is great when you can't figure out how the heck you got somewhere, and often when a stack trace isn't very enlightening, less valuable when the customer is trying to provide failure data, or you can't get access to the system until after it failed.
Dear Keil support,
Just to close the discussion we would like to ask you the following.
1) We know that using the following command:
fromelf -c --output=.\Obj\file.txt .\Obj\file.axf
we are able to get the dissasembly of the binary file with the absolute Flash memory addresses. This is fine, but this contains no C code, which is easier to understand for us.
2) On the other hand we also know that selecting:
'Options for Target xxx'-> 'Listing' -> 'Assembler Listing' 'Options for Target xxx'-> 'Listing' -> 'C Compiler Listing' 'Options for Target xxx'-> 'Listing' -> 'C Preprocessor Listing'
we are able to get the mixed C/Assembler txt module source files with relative memory addresses. This contains C/Assembler, but just relative addresses.
The question is: Is it posible to generate the mixed C/Assembler txt source files containing the absolute Flash addresses? How?
Thank you very much for your time.
Any progress on this last question regarding how to generate the mixed C/Assembler .txt source files containing the absolute Flash addresses? And How?
Thank you very much for your support.
I don't know of any way.
And I'm not too sure Keil wants any such way.
It would be so easy to write a post-processor to get code-size-limited versions of the tools to produce arbitrary-sized binaries with such output.
Are you really having so big stability issues that you need this kind of information to try to solve the problems?
Have you spent some time just checking the "standard" information available to the hardware fault handler to see if you can figure out where the exception happened and why?
Dear Keil user,
I am not Keil support nor am I affiliated with Keil in any way.
I suspect that what your requesting is a big ask.
Never needed anything like this myself. Just used map files, dis-assembly and a reasonable amount of debugging experience.