Showing results for 
Search instead for 
Did you mean: 

Semihosting does not work with codes generated by STM32CubeMX v4.15.1 on STM32F103RCT6/STM32F405RG

Posted on July 21, 2016 at 13:54

Also posted in OpenSTM32 forum

I use STM32CubeMx to generate code and import it to System Workbench following

The code keeps blinking led and outputting constant string to uart (DMA) in a loop and works as expected. I can debug it in Eclipse so everything works perfect by here.

Problem happens while experimenting with semihosting feature (see attached).

What I changed/added to enable the semihosting:

- Add ''-specs=nosys.specs -specs=nano.specs -specs=rdimon.specs -lc -lrdimon'' to linker

- Add ''initialise_monitor_handles();'' to the beginning of main()

- Add ''monitor arm semihosting enable'' to Startup of debug configuration

Seems all is set up correctly but I can't get string printed on the console. I also tried in plain makefile version (no GUI) the problem persists. Problem exists in STM32F103RCT6/STM32F405RG.

I use STM32F1 customized board and STM32F4 STM32-P405 from Olimex for testing.

Do I miss anything? Have anyone tried semihosting with STM32CubeMX and System Workbench environment?

Thanks for the support.


Rosiney Silva
Associate II
Posted on July 21, 2016 at 21:15

Can i use both options at the same time (''-specs=nosys.specs'' and ''-specs=rdimon.specs'')?

In the ''readme.txt (GNU Tools for ARM Embedded Processors)'' says




Users can choose to use or not use semihosting by following instructions.

** semihosting

If you need semihosting, linking like:

$ arm-none-eabi-gcc --specs=rdimon.specs $(OTHER_LINK_OPTIONS)

** non-semihosting/retarget

If you are using retarget, linking like:

$ arm-none-eabi-gcc --specs=nosys.specs $(OTHER_LINK_OPTIONS)



Posted on July 22, 2016 at 09:02

Figured out the problem finally!

With the items (listed above) properly set up Semihosting works when printing inside main() function.

To print inside FreeRTOS thread, need to e.g. ''invoke setvbuf(stdout, NULL, _IOLBF, 256);'' explicitly even if log strings have '\n'.

Tried both ''-specs=nosys.specs -specs=nano.specs -specs=rdimon.specs -lc -lrdimon'' and ''-specs=nano.specs -specs=rdimon.specs -lc -lrdimon'' and they work! Seems it's conflicting that nosys and rdimon co-exist. In first setting the latter rdimon spec could 'overwrite' nosys spec that's why it works as well (I guess)