printf prevents UART app working when debugger not connected

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • printf prevents UART app working when debugger not connected

      When debugging, printf directs to the debug terminal - the app seems to function
      When I build a release version I need to comment out printf otherwise the app will freeze
      How can I redirect printf output to the com port so as to prevent this?
      How is stdio set in the ses environment?

      (I am using a JLINK Edu with a Nordic development board to develop an app using a UART for serial comms)

      Many thanks for any help


      Rob
    • Check the blocking mode used in RTT: in sdk_config.h, the macro SEGGER_RTT_CONFIG_DEFAULT_MODE decides what should happen when the RTT buffer is full (not cleared by your J-Link). I bet it is set to "2" ("BLOCK, Wait until there is space in the buffer"). Switch to a non-blocking mode and recompile.
    • New

      Jev
      Belated thanks for the sound advice. Unfortunately it did not fix it.
      I found a similar suggestion from Nordic:
      devzone.nordicsemi.com/f/nordi…default_mode-blocking-app

      I get the same problem when I include the lines below in in sdk_config.h. The printf statement prevents the code running without an RTT console

      Source Code

      1. // <o> SEGGER_RTT_CONFIG_DEFAULT_MODE - RTT behavior if the buffer is full.
      2. // <i> The following modes are supported:
      3. // <i> - SKIP - Do not block, output nothing.
      4. // <i> - TRIM - Do not block, output as much as fits.
      5. // <i> - BLOCK - Wait until there is space in the buffer.
      6. // <0=> SKIP
      7. // <1=> TRIM
      8. // <2=> BLOCK_IF_FIFO_FULL
      9. #ifndef SEGGER_RTT_CONFIG_DEFAULT_MODE
      10. #define SEGGER_RTT_CONFIG_DEFAULT_MODE 0
      11. #endif
      Display All




      :(
    • New

      Huh, sounds like it doesn't take the settings from sdk_config.h. do you define USE_APP_CONFIG by any chance?

      Let's check if something weird is happening:
      1. Load your application in the SES debugger.
      2. Set a breakpoint on _DoInit.
      3. Run until the app hits this breakpoint
      4. Set a new breakpoint on the end of the function.
      5. Continue execution until the app hits this breakpoint
      6. At this second breakpoint, open a Quick Watch on p
      7. Drill down to aUp and aDown as shown below
      What are the values of the Flags?

    • New

      Thankyou for this suggestion; I hit a snag. _DoInit is a called through macro INIT() in Segger_RTT.c. However in my configuration INIT() is not called; I cannot add breakpoints in the INIT() block. Not sure why. RTT is enabled in debug options. And indeed printf directs to the debug terminal

      When I look at the assembler code for start() - attached file
      I see the following order of execution:
      Cortex_M_Startup.s
      SEGGER_THUMB_Startup.s
      system_nrf51422.c

      This seems like a candidate for the problem

      --- SEGGER_THUMB_Startup.s -- 393 --------------------------
      bx lr
      HELPER __getchar
      JUMPTO debug_getchar
      HELPER __putchar
      JUMPTO debug_putchar


      I'll investigate further

      Thanks again

      Rob
      Files
      • start.txt

        (19.4 kB, downloaded 2 times, last: )