Build without ARM semihosting

Sysprogs forums Forums VisualGDB Build without ARM semihosting

This topic contains 6 replies, has 2 voices, and was last updated by  asti 1 year ago.

Viewing 7 posts - 1 through 7 (of 7 total)
  • Author
  • #25948


    I’m targeting the NRF51 to build fruitymesh ( )

    Now NRF51 devices use the NRF5x legacy BSP.

    For compatibility reasons, I’m using their startup.s file, system_nrf51.c and linker script.

    It builds and debugs perfectly well, however, I cannot get it to run standalone because it is being built with semi-hosting.

    How do I turn off semi-hosting? The usual options to control the level of semi-hosting don’t appear.

    I’ve attached a screenshot of the embedded project page.

    I’m fine with manually editing the project files,

    You must be logged in to view attached files.



    It looks like you are using an old toolchain that doesn’t provide fine-grain control over semihosting calls. Please try unchecking the “Provide default stubs for system calls” checkbox (bottom of the 1st screenshot) and then either manually provide dummy syscall implementations, or manually specify “–specs=nosys.specs” via VS Project Properties (not VisualGDB Project Properties) -> Linker -> Command Line.




    Thank you for the suggestion.

    I had already tried ‘–specs=nosys.specs’ in vcxproj link options.

    I had also converted this to a standalone project and specified nosys in LDFLAGS. (picture attached)

    Both require semihosting. Still no luck, I’m afraid. NRF51 sdk only links properly on GCC 4.9, so I can’t upgrade to get the newer options.

    Is there anything else I could try?

    You must be logged in to view attached files.


    Thanks for confirming your license key. Specifying –specs=nosys.specs manually should normally work.

    If it doesn’t, please let us know:

    1. What exactly you are trying to achieve? I.e. why simply not calling printf() is not an option?
    2. What is the expected/observed behavior when you use the settings on the screenshot (e.g. expect the project to build, got a specific error)?

    This should help us understand what is going on.



    Thank you for your support.

    Expected behavior:

    Application runs without debugger.

    Current behavior:

    No build errors or warning.

    Application crashes without debugger attached.

    Specifically, application crashes without semi-hosting console support enabled.


    What’s happening, I think, is that newlib being used here still links with semi-hosting calls.

    I think, irrespective of me specifying nosys, it’s using rdimon. (Please see attached)

    libc is supposed to use RTT.

    Could I have missed something?


    You must be logged in to view attached files.


    Thanks for clarifying this. It could be that the old toolchain you are using does not come with dummy syscall implementations that would not trigger the semihosting calls.

    We could recommend 3 ways of solving it:

    1. Run the program without debugging, reproduce the crash, attach to it and examine the call stack. You will likely see a call to printf() somewhere that triggered the semihosting call. Simply comment it out, or make it conditional in order to remove it.
    2. Do not specify the –specs=nosys.specs at all and try building the project. Once it complains about missing _write() and other similar syscalls, provide your own implementations for them that will simply discard the data passed to them.
    3. Try using our Advanced Semihosting and Profiler framework and select the option to ignore semihosting calls when the debugger is not attached.


    So after spending some time on and off on this, and eliminating all possible sources of calling initialise_monitor_handles and the like, I finally tracked down the problem to crt0.S in the toolchain.

    Looks like the version that was shipped has a bkpt 0xab instruction baked in. So no matter what I did, it would always trigger semi-hosting. I replaced lib\thumb\cortex_m0\crt0.o with a version from a newer arm-eabi-gcc, and the problem has now gone away.

    Thank you for your guidance and clues.

    • This reply was modified 1 year ago by  asti.
Viewing 7 posts - 1 through 7 (of 7 total)

You must be logged in to reply to this topic.