Microsemi Maker-Board M2S010-MKR-KIT


Hi, I’ve been working on the EEwiki Maker-Board tutorial. Since there was not already a topic for this board, I’ve gone ahead and made one. I’ll be posting a couple questions I have, as well as tips and tricks I’ve found below.



One problem I’ve had with using this board is configuring Libero SoC on linux to program it with the generated bitstream file. Whenever I try I just get this error



I’ve searched through the settings, searched in the documentation about setting up Libero for linux environments, and also google. I haven’t found anything that works. Perhaps someone can help me with this?

Edit: To be clear, I have plugged the board in, and it shows up under /dev as “ttyUSB0”



An error I encountered but was able to fix while doing the tutorial:

When using the system builder or synthesizing, I ran into the following errors

Starting Synplify Pro ME…
/usr/local/microsemi/Libero_v11.8/Synplify/bin/synplify_pro: 137: [: unexpected operator

/usr/local/microsemi/Libero_v11.8/Synplify/bin/synplify_pro: 151: [: !=: argument expected

/usr/local/microsemi/Libero_v11.8/Synplify/bin/synplify_pro: 386: /usr/local/microsemi/Libero_v11.8/Synplify/bin/config/execute: Syntax error: “(” unexpected (expecting “;;”)

The cause of this is with several shell scripts under /usr/local/microsemi/Libero_v11.8/Synplify/bin/

When looking at the first line of the file “execute”, the shebang is “#! /bin/sh” but the file uses some syntax that sh doesn’t like, but bash can understand. E.g. lines 321 and 386 where it says “args_a=( $@ )” gives problems because of the ‘(’ and ‘)’ around the “$@” expansion

This can be fixed by fixing the shebang so that it says “#! /bin/bash” instead of sh

Under the “microsemi/Libero_v11.8/Synplify/bin/” the following files needed to be changed:


It may be possible to just link /bin/sh to /bin/bash, but that could cause problems for other programs on your system if they are not bash compatible for some reason.


Ok, here’s the solution for the “No programmer connected” error from before:

On linux, the usb device is not accessible to programs not running as root by default. However, it’s not necessary to run as root if you change the udev device rules. Another program by Microsemi, the SoftConsole program for programming onboard and soft CPU’s such as cortex M1 and M3, and RISC-V has a solution for accessing specific microsemi devices.

I used the release notes for SoftConsole 5.1 as a reference. On page 16 under the section “After Installing” they talk you through the process of adding your user account to the plugdev group (I was automatically added to the group, I’m on linux mint 18, kernel 4.4.0-112-generic. Supposedly only enterprise linux distro’s have that problem) and then you need to add the file 60-openocd.rules to your /etc/udev/rules.d/ directory. For the curious, this is why the rules start with a number.

I hope this helps someone!


Something I ran into when trying to compile the code in soft console. Only certain files need to be included from RTOS source code. This isn’t clear, especially when on linux, but under “FreeRTOSv9.0.0/FreeRTOS/Demo/CORTEX_SmartFusion2_M2S050_SoftConsole” There’s a .bat file that needs to be run to copy the proper source files for the smartFusion port of FreeRTOS. I just quickly did that on a windows vm on my linux box. See this page under the section titled “Building and executing the demo application”.

Another thing I had to do was change two lines in FreeRTOSConfig.h:

and it seems to compile fine for me. Perhaps there’s another better solution, but I am going off of this information

At this point I’m just trying to get my esp8266 to work. Technically I’m using a D1 mini borrowed from a friend. I may need to erase whatever code he had running on it.

I’m able to connect to the board via minicom with the settings provided, except I had to disable Hardware Flow Control in the minicom serial settings. Shows up under /dev/ttyUSB0 as it did in my previous post.


I was able to fix this by importing the following file:

The issue I’m running into is when I try to debug my application, GDB crashes.
It doesn’t crash if I replace my main function with the following:

int main( void ) 
    printf("Hello world\n");
    return 0;

Does the size of the generated binary have anything to do with it?

Invoking: GNU ARM Cross Print Size
arm-none-eabi-size --format=berkeley "cFS_base.elf"
   text	   data	    bss	    dec	    hex	filename
  22112	    144	  43280	  65536	  10000	cFS_base.elf
Finished building: cFS_base.siz

Running Windows8 , Libero v11.8 SP3, Softconsole 5.2.


What happens when you expand the “View problem details” section on the error window?
Also, do you have SoftConsole 5.1 or 4.0, I know you mentioned using 5.2 in your post above? I’m using 5.1, and the EEWiki mentions that 5.2 has changes that might be problematic.

Also, thanks for the help with the runtimeStats thing. I’ll try that next time I work on my board.


When I expand “View problem details” it just gives me version information for the executable as well as stating that the application crashed.

I’ll post a screenshot when I get home tonight.

I had this setup on 5.1, but was also not able to get it running. I’ll give it another go tonight to see if I can run the blinky example.


I can’t even get the smartfusion2-cortex-m3-blinky project to run with 5.1.

Here are the crash details:

I was able to recreate the problem with 5.1.

It won’t run unless I replace the contents of main with

printf("Hello world\n");


Try this
arm-none-eabi-gdb.exe exception 40000015

Otherwise, I can only think of finding log files for the …gdb.exe and reading through that. I’m trying to figure out where that would be.


Ok, I’ve been able to get it running and connecting to thingspeak.
I used @bkzshabbaz 's suggestion for including the RunTimeStatsTimer.c file, and I made one additional change.
Connecting directly to my ESP worked through minicom, but I had to use 115200 baud, and each time after hitting enter, I had to do Ctrl+j to send a new line char. I changed the baud rate being used in the main.c file to match

After that, everything worked!



I don’t have any breakpoints set. This is so frustrating.


@windowsnt which Linux distribution are you using?


Have you tried SoftConsole v4.0? That’s what the tutorial was written with.
Does any code other than Hello World work? Or does it specifically have to be that printf statement?
When GDB crashes, does it happen immediately or does some code execute on the board first?

Also thanks @windowsnt for pointing out the bit about the FreeRTOS .bat file. And changing the baud rate for the ESP (which seems to vary depending on the firmware). I’ll make a note of those on the wiki.


Linux Mint 18 as the main OS, and then I have others along with windows in a VM. Thank you for the tip about minicom. Somehow I didn’t find that when I searched.

I’ll try this on windows with all the versions of SoftConsole I have for windows when I get home. If I’m able to get the same error, we’ll at least know it’s unlikely to be anything specific to your machine. Sorry I can’t be of more help.


Did you use any guides to get libero and softconsole working on Mint? I use Xubuntu as my main OS and am running all of this in a Windows 8 VM at the moment. I would definitely prefer to have all this running on my native Linux install.


I used the guide here:

For the SoftConsole installation, I used only the instructions provided by Microsemi, along with the release notes I mentioned above.
One thing to note, I had to mark the installer as executable, and run it as root in the termial, Otherwise, Cinnamon (Desktop Environment) kept crashing. On windows, I just had to double click it.


Actually, let me clarify. There were a few other things I had to do.

Install libmotif

I think I also had to resolve the dependencies for libmotif.

Install LSB

sudo apt-get install lsb

This was particularly frustrating because when I tried to run the licensing daemon, it would just say “File or path not found” with no context. I ended up finding the solution on a forum for a completely different program that used the same licensing daemon.


How did you add the board to USB when using a windows VM?

I tried on v5.1 on windows and got this error



Strange, I did it in v4.0 and it works. Not sure if the vm has anything to do with it.