Broke debug_vprintf: Unrecoverable Failure
I have a short function which calls debug_vprintf. This has worked in debug and release configurations for years, but now it no longer works in release mode.
Until yesterday, the result that I was getting was that when debug_vprintf was called, I'd get a message "Unrecoverable Failure. CrossStudio must close." Today, I get different results: debug_vprintf prints garbage text the first time, and the second time, I get DEV_TARGET_CMD_ERR.
I don't know when the problem started. When I rebuild old versions that I believe previously worked, I get the problems now. That suggests that I changed a (tools, options) default setting that isn't overridden by any solution or project configuration settings.
When I stripped the program down, I was able to eliminate the problem by setting the project's GCC target to elf, but that's not a solution because the full program needs -std=c++11, which seems to not work with elf targets. When the GCC target is set to EABI, I get incorrect text output, then DEV_TARGET_CMD_ERR.
It appears that debug_vprintf is getting a bad parameter that causes it to print bad text, or crash the debugger, but when I print the actual parameters with debug_printf (not debug_*v*printf), they print correctly, so I know the parameters to my function are still correct.
If I create a new nearly-empty project, debug_vprintf works in release mode, so the underlying mechanism is still intact.
Does anybody have any idea what I could have changed that is retained outside of normal *.hzp and source files, that could cause debug_vprintf to kill the entire IDE?
I'm using CrossWorks for ARM release 2.3.5 for Windows x86.
Here's my function:
void debugout(const char *msg, ...)
{
uint32_t _saved_primask = __get_PRIMASK();
__disable_irq();
va_list vl;
va_start (vl, msg);
debug_vprintf(msg, vl);
__set_PRIMASK(_saved_primask);
}
-
I have it (mostly) figured out now.
It wasn't a stack problem. I added 3000 bytes to both the process stack and the main stack. That didn't fix the text output, but might have prevented the DEV_TARGET_CMD_ERR.
I compared the configurations of two different programs and found that the one with problems had library optimization set to "small" in its release configuration. When I changed it to "fast", the problem went away.
The reason it broke after working for years is that it was originally (5 years ago) a macro that called debug_printf (no "v"), which worked with the small library. Two years ago, I changed it to debug_vprintf, which doesn't work with the small library, but since debug output is usually disabled in release mode, the problem didn't appear until recently when I enabled it.
So now I understand why it quit working recently, but I still have some questions: Why doesn't debug_vprintf work with library optimization = "small"? Is that known? Does the documentation somewhere say that? If I need the small library and debug_vprintf, is there a simple configuration change that will allow them to work together?
Thanks.
-
I've just tried debug_vprintf here in small library configuration and it is working OK. What you are describing sound like memory corruption problems. Changing optimization levels will alter memory layout and stack usage - the most likely cause of problems like this is insufficient stack allocation.
-
I added 15,000 bytes to both stacks, and that didn't change anything.
I created a new STM3210E_EVAL project with nothing except calls to debug_vprintf, and it still prints garbage when the small library is used. In the configuration, I changed the processor to STM32F103ZC, library optimization to "small", main and process stacks to 4000 bytes, and heap to 4000 bytes. If I use the fast library, there is no problem. I get the same results if I use the ARM simulator target instead of a real board.
Is it possible that my library has been corrupted, perhaps when Windows didn't shut down properly? If so, would re-installing Crossworks (without first un-installing) repair that?
Is it at all possible that there's a bug in the library? Or are they tested so thoroughly that that's completely implausible?
When this line runs:
debugout("One","two","three","four","five","six");the output is
three
Does that give any clues?
Please sign in to leave a comment.
Comments
4 comments