We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Recently I ran into a problem with printf(). Right away I noticed that the firmware was caught in a function named os_error(). In the function the comments state to look at RTL.h to for error codes. However, the error code that I have 0x48=72 is not listed.
What is the best way to find out what error 72 is?
I am using MDK-ARM 4.11 for my toolchain.
Check for stack overflow.
I don't know what is error 72, but using printf can implicitly use much of stack (and maybe stack overflow also disrupt the parameters of os_error).
Thanks, you are right about stack overflow. This was the problem.
It looks like if a parameter is passed to a function, but it is not used within that function the Keil uVision IDE does not show the correct value for it. After I placed a switch-case based on the err_code argument the value returned was OS_ERR_STK_OVF.
Yes. This is debugger problem that I met a lot. The easy way for me to inspect the true contents of parameters in such case is watching the registers (if they not overwrite - the first parameter is passing in R0 and so on).
There is similar bug with local variables, that the debugger doesn't show their true content sometimes. So I track for the in the disassembly code and watch the matching register (at least with uVision version that I work with - 3.90).
... the Keil uVision IDE does not show the correct value for it.
Most likely due to optimisation ?
Or, perhaps, as the parameter is not used, the compiler does not generate debug info for it?
You are right. The optimization (Level 0-3) as well as compiler settings (e.g. "One ELF Section per Function") have significant impact on the feedback tat the IDE can give to the devleoper.
Optimization = Level 0 (-O0). The local variable or the parameter is used.
It seem that maybe the debugger is assume that the local variable is placed in register but this register is used for other things also. (Maybe it fixed in newer versions).
It is common for optimizing compilers to place parameters and local variables in registers, and then reuse the registers as soon as the original value is not needed anymore.
That means that a debugger may correctly display the parameter or local variable for some of the source code lines, but then suddenly start to display completely different values for other lines of the source code.
In short - never expect the debugger to be able to display correct values for parameters and local variables when debugging an application compiled with optimization. Your best bet is to look at the variable contents when the current execution is on a source line that makes use of the variable - except of course that the execution order can have been changed, making the debugger jump up and down in the source file.