SW4STM32 and SW4Linux fully supports the STM32MP1 asymmetric multicore Cortex/A7+M4 MPUs

   With System Workbench for Linux, Embedded Linux on the STM32MP1 family of MPUs from ST was never as simple to build and maintain, even for newcomers in the Linux world.
And, if you install System Workbench for Linux in System Workbench for STM32 you can seamlessly develop and debug asymmetric applications running partly on Linux, partly on the Cortex-M4.
You can get more information from the ac6-tools website and download two short videos (registration required) highlighting:

System Workbench for STM32

The discussion of standard IO dynamic switching among semihost, UARTx, and NULL on STM32

Hi all friends,
I had quick experiment of using semihost on OpenSTM32 toolchain. It is a nice feature on ARM processor, by define the standard device to semihosting debug channel, the standard IO functions are available before many other device initializations to be done. However, there are downsides to using semihosting. One of them is that in the code once enable/using semihosting, there has to be a debugger connected and turned on the debugging message channel, or the processor will hanging.
Considering over those disadvantages, I’m thinking to implement a set of enhanced standard IO, which can dynamic remap the standard Input/Output among semihost, UARTx and NULL. This will help different phase of developing, in field event logging, release version performance optimizing etc.
I believe this is viable. Most of the work would be patch the newlib and supply an override version of _read() and _write() function.
Would someone willing help me and working together?
Any comments and suggestions are welcome.


Anyone want to involve the discussion?
There is one thing I need to find an answer.
What is the better way to deal with initialise_monitor_handles() ?
I had searched around, to enable semihosting when using System Workbentch toolchain, it required in user code to invoke initialise_monitor_handles() at early time, such as first in main(). This is only be a little inconvenient for users who certainly want to enable semihosting, but be a trouble for my implementation. As I find out, once invoke initialise_monitor_handles(), it has to be to have a debugger semihosting channel connected, or the Arm core was hanging.
As I mentioned, I want to implement a patch to newlib, which allow to redirect/retarget the standard Input/Output and Error Output between semihosting, Uartx, Null etc. So, I will like to hold off to invoke initialise_monitor_handles() as later as possible, until the moment it is absolute necessary. There is another question, is there a way to deinitialize semihosting/monitor_handles?



If you only want to implement console I/O using semihosting, the best way to go would probably be to add a file defining the __io_getchar and __io_putchar functions called by read/write as defined in syscalls.c as well as the initialise_function_handles function.

To avoid multiple definitions you must make the empty initialise_monitor_handles function to be weak in syscalls.c by adding __attribute__((weak)) in front of its definition.

To call initialise_monitor_handles can be done directly from the startup code (adding “bl initialise_monitor_handles” before “bl main”) but you can avoid modifying the startup file (which is in assembly language) by adding the constructor attribute to your definition of initialise_monitor_handles:
__attribute__((constructor)) void initialise_monitor_handles()  {
    // Your initialisation code

Then if you include your file, you get semihosting, if you don’t, you don’t even try to initialise it...

Bernard (Ac6)

Hi Bernard,
Thank you for support.
By searching around, I feel that it seems making more senses to override couple of system call functions to achieve my goal.
I want to implement a standard Input/Output and Error to be run-time switching between semihosting debug channel, NULL, UARTx and more. I thought the best to do it is that overrider the below system call functions:
_open(,,,) , _close(,,,) , _read(,,,) , _write(,,,) .

As such, the application code can do things like freopen(“/dev/semihosting”,”w”,stdout); freopen(“/dev/null”,”w”,stdout); freopen(“/dev/ttyS0”,”w”,stdout); freopen(“/dev/ttyS1”,”w”,stdout); etc. and after then the printf(“sothing to output to std”); will output the steam to the devices properly,

As this moment, I had successfully direct the standard output through debug semihosting and UART1 and UART2 respectively, on a STM32F4 Discovery board, hard coded, can’t redirect at run-time.
There some issues I need to resolve.
The first one is that, once in the user code has some of initialization code executed for semihosting, it has to have the debugger semihosting connected, or the firmware will hanging. This problem will to be some sort of critical to preventing the standard Input/Output to be redirecting at run-time. I was heard about someone talking that if carefully handling it in NMI, this firmware hanging can be prevented. I want to find more details if anyone can provide me more information.
The second question is, what is the best strategy to override the system call functions? At this moment what I did to enable semihosting is to add link flag ” -specs=rdimon.specs -lc -lrdimon “. This liked a version of newlib and preventing me to rewrite/override some of system call function. Can someone suggest me the link flag in order to allow me to override the sys call functions of _open(,,,) , _close(,,,) , _read(,,,) , _write(,,,) , and meanwhile avoid to have to do many other unnecessary codings?


I need to patch the newlib which comes with System Workbench.
Question is, where I start? How I can get the version of source code for the newlib with System Workbench?


Hello here,
I had done a quick hack based on the syscalls.c from AC6 and liviu Ionescu’s work. As I said, it is a quick hack, but works well. In the application code, invoke
to redirect the standard Output to null, semihosting , UART2 , UART3 etc.
Null means to drop all of the data to standard Output.

I have the zip file attached here, in hoping to help someone.
Again, as I said, this is a hack, the code was far away from clean and neat, and only support stdout. Of course, the similar way can apply to stdin. It is welcome for peoples to refine the code and provide a clean neat and enhanced version.