Broke debug_vprintf: Unrecoverable Failure

Comments

4 comments

  • Avatar
    Jon Elliott

    Make sure you're not running out of stack.

    0
    Comment actions Permalink
  • Avatar
    D Kaden

    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.

     

    0
    Comment actions Permalink
  • Avatar
    Jon Elliott

    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.

    0
    Comment actions Permalink
  • Avatar
    D Kaden

    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?

     

    0
    Comment actions Permalink

Please sign in to leave a comment.