The objective of this blog is to show you the steps necessary to add the Micrium OS File System to an EFM32GG11. I'll be focusing on RAM Disk as the storage media while we wait for an SD card example project to become available.

Baseline Project

Since the Gecko SDK currently ships without a stand-alone Micrium OS File System example, we will start with the 'micriumos_usbhmsc' project for the SLSTK3701A_EFM32GG11. The convenience of selecting this project as a baseline is due to the fact that the Micrium OS File System is present as a requirement from USB-Host Mass Storage Class, which is what that example demonstrates.

Start by connecting your SLSTK3701A_EFM32GG11 to the PC and launching Simplicity Studio, then click on File -> New -> Project...

Select Silicon Labs MCU Project and click Next >

Since you already have your board connected, it should all be auto-detected. Leave everything by default making sure that there's an SDK selected, then click Next >

Now select Example - Create a working example for the part. and click Next >

In the search bar, type "SLSTK3701A_micriumos_usbhmsc", then select it and click Next >

Pick a name for your project, in my case, I named the project "SLSTK3701A_micriumos_ramdisk". Make sure you select Copy contents so that we can edit the example files freely. After that, click Finish.

Try to build the project and flash it to make sure that it is functional, remember, this will be our baseline for what's coming next...

Configuration Files

We will now need to modify the project configuration files in order to include Micrium OS FS RAM Disk as part of our build.

For that, start by expanding the Includes section in the Project Explorer panel, then expand the configuration folder as shown in the image below. After that, double-click on rtos_description.h to open it in the editor.

As soon as you try to edit rtos_description.h, you'll be presented a Warning indicating that you are editing an SDK file. Click on Make a Copy so that we can edit this freely in our workspace without affecting other projects in the SDK.

Add the following #define in rtos_description.h to indicate Micrium OS that you want to use the File System RAM Disk implementation:

#define  RTOS_MODULE_FS_STORAGE_RAM_DISK_AVAIL

 

Editing the Example Files

At this point, your application is able to create a RAM Disk using the Micrium OS File System. However, we want it to do some more. Let's now perform a simple file read and write. For that, copy the ex_fs_file_rd_wr.c and .h example files located at:

C:\SiliconLabs\SimplicityStudio\v4\developer\sdks\gecko_sdk_suite\v2.3\app\micrium_os_example\fs

 

Paste the two files in your workspace folder, at the same level of ex_fs.c, etc. In my case, this would be:

C:\Users\<user>\SimplicityStudio\v4_workspace\SLSTK3701A_micriumos_ramdisk\src

 

To make use of the read/write example that we just copied, we have to include its header file in the include section of ex_fs.c:

#if  (defined(RTOS_MODULE_FS_STORAGE_RAM_DISK_AVAIL))
#include  <fs/include/fs_ramdisk.h>
#include  "ex_fs_file_rd_wr.h"
#endif

 

Notice that I included the example header within the RTOS_MODULE_FS_STORAGE_RAM_DISK_AVAIL section in case you want to exclude the RAM Disk from your project later on then this also gets excluded.

Finally, let's add the call to Ex_FS_FileRdWr(). You can do this in Ex_FS_Init() in ex_fs.c right at the end of the "FORMAT RAM DISK" section as indicated by the code comments.

#if  (defined(RTOS_MODULE_FS_STORAGE_RAM_DISK_AVAIL))
    {
        FS_BLK_DEV_HANDLE  blk_dev_handle;


        blk_dev_handle = FSBlkDev_Open(FSMedia_Get("ram0"), &err);
        APP_RTOS_ASSERT_CRITICAL(err.Code == RTOS_ERR_NONE, ;);

        FSCache_Assign(blk_dev_handle,
                       Ex_FS_DataPtr->CachePtr,
                       &err);
        APP_RTOS_ASSERT_CRITICAL(err.Code == RTOS_ERR_NONE, ;);

        FS_FAT_Fmt(blk_dev_handle,
                   FS_PARTITION_NBR_VOID,
                   DEF_NULL,
                   &err);
        APP_RTOS_ASSERT_CRITICAL(err.Code == RTOS_ERR_NONE, ;);

        FSBlkDev_Close(blk_dev_handle, &err);
        APP_RTOS_ASSERT_CRITICAL(err.Code == RTOS_ERR_NONE, ;);

        Ex_FS_FileRdWr();
}
#endif

 

Running the Example

You can now build your application and flash it on the board. Before running it though, open a terminal application to view the VCOM output from the EFM32GG11 VCOM port.

Since we based this project out of the USB-Host Mass Storage Class example, there will still be USB-related code executing, hence why you'll see those messages in the terminal output.

Once you start running, the File System will be initialized with a default configuration, as well as the RAM Disk as specified by Ex_FS_RAM_Disk_Cfg in ex_fs.c.

Further on, the RAM Disk gets formatted as a FAT volume and one partition is created.

Lastly, the read/write example essentially writes some known data to a specified file, then the data from the file is read and verified for integrity.

If everything ran correctly, you should see the following on your terminal output:

*** MicriumOS USB-host Example. ***
FS Example: File rd/wr on 'ram0'...OK


*** MicriumOS USB-host Example -----> Init done. ***

>> Ex_FS_MediaOnConn(): Media 'ram0' connected!

 

Notice the string "FS Example: File rd/wr on 'ram0' ...OK" indicating that the read/write demo ran fine on our RAM Disk.

We hope to have a part 2 of this blog which would be based on an SD card instead of the RAM Disk. For now, this will be good enough to get your hands dirty with the Micrium OS File System.

Introduction

Micrium OS Network collects run-time statistics, error counters and buffer usage information that are optional during compile-time since they require additional code and memory.

Application developers may want to analyze these run-time metrics for various reasons:

 

Verify Performance

The protocol statistics allow you to verify the performance of your network application by looking at reception and transmission speeds.

 

Detect Errors

Error counters allow you to debug run-time problems such as low memory conditions, slow performance and packet loss.

 

Optimize Memory Usage

The buffer statistics allows you to optimize the memory usage and since the examples in Simplicity Studio are configured for general purpose and may have more buffers than necessary, these metrics can help you optimize the memory usage for your specific application needs.

 

Monitor Network Connections

The sockets list screen allows you to see the state of your incoming and outgoing network connections, including the IP addresses, port numbers and the protocol.

 

 

How to Enable the Micrium OS Network Run-Time Statistics

To enable run-time statistics within Micrium OS Network a few macros need to be defined to DEF_ENABLED as follows.

Run-time Statistics Counters

These statistics are related to the network protocol and interfaces. You may want to analyze statistics counters to verify the performance of your network application on a per interface basis. To enable them, edit the file net_cfg.h and set the following macros to DEF_ENABLED as shown below:

    #define  NET_CTR_CFG_STAT_EN                                DEF_ENABLED

 

Run-time Error Counters

Micrium OS Network maintains run-time counters for tracking error conditions within the Network Protocol Stack. You may want to analyze error counters to debug runtime problems such as low memory conditions, slow performance and packet loss. To enable them, edit the file net_cfg.h and set the following macros to DEF_ENABLED as shown below:

    #define  NET_CTR_CFG_ERR_EN                                 DEF_ENABLED

 

Network Statistics Pool configuration

These statistics are related to data buffers. You may want to analyze these statistics to optimize the memory usage of your network application. To enable them, edit the file net_cfg.h and set the following macros to DEF_ENABLED as shown below:

    #define  NET_STAT_POOL_BUF_EN                               DEF_ENABLED

    #define  NET_STAT_POOL_ARP_EN                               DEF_ENABLED

    #define  NET_STAT_POOL_NDP_EN                               DEF_ENABLED

    #define  NET_STAT_POOL_IGMP_EN                              DEF_ENABLED

    #define  NET_STAT_POOL_MLDP_EN                              DEF_ENABLED

    #define  NET_STAT_POOL_TMR_EN                               DEF_ENABLED

    #define  NET_STAT_POOL_SOCK_EN                              DEF_ENABLED

    #define  NET_STAT_POOL_CONN_EN                              DEF_ENABLED

    #define  NET_STAT_POOL_TCP_CONN_EN                          DEF_ENABLED

 

Internet Group Management Protocol (multicast) layer configuration

    #define  NET_MCAST_CFG_IPv4_RX_EN                           DEF_ENABLED

 

 

How to Analyze the Micrium OS Network Run-Time Statistics

To access these run-time statistics, you can either watch the arrays and variables from your IDE's watch window or call some APIs from your application. However, that quickly proves to be impractical. Instead, you can use uC/Probe, a tool that is integrated in Simplicity Studio that allows you to watch these statistics live in a series of pre-built screens as shown in the following image:

 

 

Installing uC/Probe

uC/Probe can be installed and integrated in Simplicity Studio by following the next steps:

• Open Simplicity Studio
• Click Help from the top menu
• Select the option Update Software from the Help menu
• Switch to the Tools tab
• Scroll-down and press the button Install next to the option Micrium uC/Probe

 

 

Opening uC/Probe

To open uC/Probe launch a Debug Session for your project and press the button uC/Probe located on the top toolbar of Simplicity Studio as shown below:

 

 

Associating uC/Probe to your Embedded Application

Typically uC/Probe will launch and open your project’s ELF file in the Symbol Browser as shown in the image below:

However, if the Symbol Browser is empty, then you need to press the button ELF and locate your project’s output file typically located in your toolchain’s output folder. For example:

• GNU: PROJECT_LOC/GNU ARM vx.x.x - Debug/MyOutputBinary.hex
• IAR: $PROJ_DIR$/[Project Name]/Exe/MyOutputBinary.out

 

 

Including the Micrium OS Network Screens

uC/Probe is a Windows tool that lets you associate a virtual indicator and/or control to any of your embedded application’s global variables, and then display the variables values live in a dashboard.

However, for the run-time statics maintained by the Micrium OS Network stack, a series of screens are already designed and configured to display said statistics.

To include the screens, follow the next steps:

• Locate the Workspace Explorer on the top left corner of uC/Probe.
• Click the button Insert Screens
• Select the option Micrium OS Net (TCP/IP)

 

 

Watching the Run-Time Statistics Live

To start watching the run-time statistics live, ensure that your embedded application is running and press the button Run located on the top toolbar of uC/Probe as shown in the following image:

 

Conclusion

To ensure the highest level of performance possible, it makes sense to start your Micrium OS Network based application by defining as many buffers as possible and then use uC/Probe and its interface and pool statistics data screens in order to refine the number after having run the application for a while. For example, a busy network will require more receive buffers in order to handle the additional messages that will be received.

 

 

 

 

Overview

Micrium has a long history of providing very reliable kernels as seen with uC/OS-II and uC/OS-III, both still sold and used in many products today. Micrium OS Kernel is no exception to this and one common trait seen across all of these kernels is they are extremely configurable. A common question developers ask when evaluating real-time kernels is what is the kernel’s footprint for RAM and ROM. Micrium OS Kernel does not have a set number for RAM or ROM but instead a general range: 6-24KB ROM and 3-4KB of RAM. The reason for this is every part of the kernel, with the exception of the scheduler, can be enabled or disabled through a number of configuration header files.

Micrium OS Kernel by default uses an internal heap to allocate memory for its internal data structures and internal task stacks. The heap provides a simple, convenient way to allow a user to get a kernel project up and running quickly. The drawback to using the heap is there may be some RAM allocated to the heap that ends up not being used. This article will cover how to modify the Giant Gecko Series 1 Starter Kit (SLSTK3701A) Micrium OS Blink example to disable the internal heap and statically allocate memory for the internal data structures and task stacks. Nothing covered in this example is specific to the Giant Gecko Series 1, so these steps can be taken on any Micrium OS Kernel project.

Note: The file that is being modified, ex_main.c, is available for download at the bottom of this post.

Creating the Micrium OS Blink project

These steps assume Micrium OS Kernel is already installed in the most recent SDK version of a Simplicity Studio install. If it is not, go through the Update Software wizard for the Giant Gecko Series 1 to install all of the necessary packages.

 

Go to File -> New -> Project… to bring up the new project wizard. Select Silicon Labs MCU Project and click Next.

Set the board to the EFM32GG11 Giant Gecko Starter Kit board. This should trigger the Part and SDK to be set. If it does not, set the part as shown above and choose the most recent version of the SDKs.  Note: Micrium OS Kernel must already installed before this step. 

Select Example and click Next. 

Search for the Micrium OS Blink project and click Next. 

Select either Link Libraries or copy sources or Copy contents. It Is important that the ex_main.c file is copied into the project so modifications can be made. Click Finish and the project will be loaded into the Simplicity IDE.

Modifying the configuration files

Starting with the blank Micrium OS Blink project, expand the micriumos_blink/cfg folder as shown above under the Includes folder. This folder has all of the Micrium OS configuration files.

#define  LIB_MEM_CFG_HEAP_SIZE  0uL

The first step is to set the Micrium heap to zero. In common_cfg.h there is a #define for LIB_MEM_CFG_HEAP_SIZE. This value defines the size of the Micrium OS heap and should be changed to 0. After setting the heap value to 0, the project would still compile without error but would fail to run as the memory allocation would fail during OSInit().

If presented with a warning similar to the above, select Make a Copy. Any edits made to header files in the SDK would affect all future Micrium OS projects.

#define  RTOS_CFG_EXTERNALIZE_OPTIONAL_CFG_EN  DEF_ENABLED

After disabling the heap, Micrium OS needs to be set to disable the default configurations for all internal data structures and task stacks. Open up rtos_cfg.h and locate the #define for RTOS_CFG_EXTERNALIZE_OPTIONAL_CFG_EN. Change it to DEF_ENABLED to disable the default configurations. At this point, compilation of the project will fail due to a number of InitCfg structures not being set.

Configuration Structs

The rest of the code for this walk-through will be written in ex_main.c. There are three structures that must be defined: OS_InitCfg, Common_InitCfg, and PlatformMgr_InitCfg. These structures are used internally in Micrium OS and by setting RTOS_CFG_EXTERNALIZE_OPTIONAL_CFG_EN to DEF_ENABLED, the default configs for these structs has been removed and must be implemented by the developer.

OS Config Structs

struct  os_init_cfg {
    OS_STACK_CFG         ISR;
    OS_MSG_SIZE          MsgPoolSize;
    CPU_STK_SIZE         TaskStkLimit;
    OS_STACK_CFG         IdleTask;
    OS_TASK_CFG          StatTaskCfg;
    OS_TASK_CFG          TickTaskCfg;
    OS_TASK_CFG          TmrTaskCfg;
    MEM_SEG             *MemSeg;
};

The OS_INIT_CFG structure defines all of Micrium OS Kernel’s runtime configuration. It contains the stack config for all of the internal tasks (Idle, Tick, Timer, Stat), as well as the interrupt stack and an internal memory segment for internal kernel objects. The TaskStkLimit parameter will be set to zero as it is no longer used, but remains for backwards compatibility with previous versions. If an internal task has been disabled in os_cfg.h, that task’s configuration can be omitted from the OS_InitCfg.

struct  os_task_cfg {
    CPU_STK             *StkBasePtr;
    CPU_STK_SIZE         StkSize;
    OS_PRIO              Prio;
    OS_RATE_HZ           RateHz;
};

The OS_TASK_CFG structure is used to configure the Tick task, Statistics task and the Timer task. Each task will need a stack size and memory allocated for it, a priority set and the rate that the task will run at. Its important to remember that the stack size is not in bytes but stack units which are set to the width of the CPU (32 bits in this case); so a stack size of 128 stack units results in a 512 byte stack. Also, the timer task and stat task can not have a rate higher than the tick task due to being based off of the OS tick rate.

struct  os_stack_cfg {
    CPU_STK             *StkBasePtr;
    CPU_STK_SIZE         StkSize;
};

The OS_STACK_CFG structure is used for the Idle task and the ISR stack. Neither task has a priority (idle task defaults to the lowest priority, ISR is for interrupt context only) or rate associated with the task, so it only contains the stack size and location.

Common Config Struct

typedef  struct  common_init_cfg {
    MEM_SEG             *CommonMemSegPtr;

#if (RTOS_CFG_LOG_EN == DEF_ENABLED)
    COMMON_CFG_LOGGING   LoggingCfg;
    MEM_SEG             *LoggingMemSegPtr;
#endif
} COMMON_INIT_CFG;

The COMMON_INIT_CFG struct is used during the init of the common module. Typically the CommonMemSegPtr is set to DEF_NULL and logging is disabled. For this example, this will also be the case.

Platform Manager Struct

typedef  struct  platform_mgr_init_cfg {
    CPU_SIZE_T  PoolBlkQtyInit;
    CPU_SIZE_T  PoolBlkQtyMax;
} PLATFORM_MGR_INIT_CFG;

The PLATFORM_MGR_INIT_CFG struct is used for the initialization of the platform manager module. This module is used to describe hardware capabilities of peripherals such as network interfaces, USB interfaces or file systems.  Normally the platform manager pulls in memory from the heap but for a kernel-only project no memory is needed so the number of blocks can be set to zero. Unfortunately even though the platform manager is not used in a kernel-only project, a configuration is still required.

Configuring Micrium OS Blink

Using the information covered in the previous section, this part will cover how to configure ex_main.c in the Micrium OS Blink project to use these configuration structures.

Kernel Config Defines

This section covers only using #defines to set configurations. Since all internal tasks are configurable these defines will check to see if the tasks are enabled before adding them to the overall OS config.

//////////////////////////////
// Micrium OS Configuration //
//////////////////////////////
#define  TICK_TASK_RATE_HZ                  1000u
#define  STAT_TASK_RATE_HZ	                 100u
#define  TIMER_TASK_RATE_HZ                   10u
#define  MSG_POOL_ELEMENTS                     5u

/////////////////////
// Task Priorities //
/////////////////////
#define  TICK_TASK_PRIO                        0u
#define  TIMER_TASK_PRIO                       4u
#define  STAT_TASK_PRIO                        5u
#define  EX_MAIN_START_TASK_PRIO              21u

//////////////////////
// Task Stack Sizes //
//////////////////////
#define  TICK_TASK_STK_SIZE                  128u
#define  STAT_TASK_STK_SIZE                  128u
#define  TIMER_TASK_STK_SIZE                 128u
#define  IDLE_TASK_STK_SIZE                  128u
#define  ISR_STK_SIZE                        128u
#define  EX_MAIN_START_TASK_STK_SIZE         512u

The first step is to set some defines for the kernel configuration. This includes the task stack sizes and priorities, the internal task rates and the message pool elements.

• Task priorities can range from 0 to OS_CFG_PRIO_MAX (defined in os_cfg.h) with 0 being the highest priority.
• The task stack sizes are specified in stack units which correspond to the width of the CPU, not bytes, so it is important to remember that a stack size of 128 stack units is actually 512 bytes.
• The rates for the tick, timer and stat task are specified in hertz. Typical tick rate for the tick task is 1000Hz, typical timer task rate is 100Hz and typical stat task rate is 10Hz.

////////////////////////////////
// Message Pool Configuration //
////////////////////////////////

#define  MSG_POOL_SIZE      MSG_POOL_ELEMENTS * sizeof(OS_MSG)
#define  MSG_POOL_CFG       .MsgPoolSize     = MSG_POOL_ELEMENTS, \
							.MemSeg          = &MsgPoolMemSeg,

The next section to define is the message pool configuration. The message pool is used for the message queues and the number of message pool elements should always match the total number of queue entries in the entire system. For example if there is one OS Queue that has 10 entries and one OS Task Queue with 20 entries, MSG_POOL_ELEMENTS should be set to 30 to guarantee there is enough entries available for all of the message queues.

/////////////////////////////
// Tick Task Configuration //
/////////////////////////////
#if (OS_CFG_TASK_TICK_EN == DEF_ENABLED)
#define  TICK_TASK_CFG                  .TickTaskCfg =                        \
                                        {                                     \
                                            .StkBasePtr = &TickTaskStk[0],    \
                                            .StkSize    = TICK_TASK_STK_SIZE, \
                                            .Prio       = TICK_TASK_PRIO,     \
                                            .RateHz     = TICK_TASK_RATE_HZ   \
                                        },
#else
#define  TICK_TASK_CFG
#endif

/////////////////////////////
// Stat Task Configuration //
/////////////////////////////
#if (OS_CFG_STAT_TASK_EN == DEF_ENABLED)
#define  STAT_TASK_CFG                  .StatTaskCfg =                        \
                                        {                                     \
                                            .StkBasePtr = &StatTaskStk[0],    \
                                            .StkSize    = STAT_TASK_STK_SIZE, \
                                            .Prio       = STAT_TASK_PRIO,     \
                                            .RateHz     = STAT_TASK_RATE_HZ   \
                                        },
#else
#define  STAT_TASK_CFG
#endif

//////////////////////////////
// Timer Task Configuration //
//////////////////////////////
#if (OS_CFG_TMR_EN == DEF_ENABLED)
#define  TIMER_TASK_CFG                 .TmrTaskCfg =                         \
                                        {                                     \
                                            .StkBasePtr = &TimerTaskStk[0],   \
                                            .StkSize    = TIMER_TASK_STK_SIZE,\
                                            .Prio       = TIMER_TASK_PRIO,    \
                                            .RateHz     = TIMER_TASK_RATE_HZ  \
                                        },
#else
#define  TIMER_TASK_CFG
#endif

The Tick Task, Stat Task and Timer Task all use the OS_TASK_CFG structure so using the values defined from the Micrium OS Configuration section above, their declarations are fairly similar. The only variable not yet covered in these structs is the stack pointer. The stack pointer variables will be declared a littler farther down in ex_main.c, right now this is just #defines to be included later on.

/////////////////////////////
// Idle Task Configuration //
/////////////////////////////
#if (OS_CFG_TASK_IDLE_EN == DEF_ENABLED)
#define  IDLE_TASK_CFG				   .IdleTask =                            \
                                       {                                      \
                                           .StkBasePtr  = &IdleTaskStk[0],    \
                                           .StkSize     = IDLE_TASK_STK_SIZE  \
                                       },
#else
#define  IDLE_TASK_CFG
#endif

///////////////////////
// ISR Configuration //
///////////////////////
#define  ISR_CFG                       .ISR =                                 \
                                       {                                      \
                                           .StkBasePtr  = &ISRStack[0],       \
                                           .StkSize     = ISR_STK_SIZE        \
                                       },

The idle task and ISR configuration both use OS_STACK_CFG. Similar to the ones using OS_TASK_CFG, these configs use the stack size defines from the Micrium OS Configuration section above and the stack variables will be defined later on.

////////////////////////////////
// Micrium OS  Configurations //
////////////////////////////////
#define  OS_INIT_CFG_APP            {                                \
						                ISR_CFG                      \
							            IDLE_TASK_CFG                \
							            TICK_TASK_CFG                \
							            STAT_TASK_CFG                \
							            TIMER_TASK_CFG               \
                                        MSG_POOL_CFG                 \
                                        .TaskStkLimit = 0u,          \
                                    }

#define  COMMON_INIT_CFG_APP        {                                \
                                        .CommonMemSegPtr = DEF_NULL  \
                                    }

#define  PLATFORM_MGR_INIT_CFG_APP  {                                \
                                        .PoolBlkQtyInit = 0u,        \
                                        .PoolBlkQtyMax  = 0u         \
                                    }

Using the #defines for the message pool, internal tasks and the ISR stack, the OS_INIT_CFG_APP define can be set. As mentioned earlier the TaskStkLimit can be set to zero as it is no longer used.

The COMMON_INIT_CFG_APP define only has one variable, CommonMemSegPtr defined. The other variables in the struct are only enabled if the logging module is enabled. Since no modules in common need memory for this application the MemSegPtr will be set to DEF_NULL to signal it is not in use.

The PLATFORM_MSG_INIT_CFG_APP define is similar to COMMON_INIT_CFG_APP, the two fields in it can be set to zero as its not needed for this application.

Kernel Config Variables

Now that the defines have all been set, the stacks need to be created and the config defines need to be set to the necessary variables for Micrium OS Kernel to pull them in.

//////////////////////////
// Micrium OS Variables //
//////////////////////////

#if (OS_CFG_TASK_IDLE_EN == DEF_ENABLED)
static  CPU_STK  IdleTaskStk[IDLE_TASK_STK_SIZE];
#endif

#if (OS_CFG_TASK_TICK_EN == DEF_ENABLED)
static  CPU_STK  TickTaskStk[TICK_TASK_STK_SIZE];
#endif

#if (OS_CFG_STAT_TASK_EN == DEF_ENABLED)
static  CPU_STK  StatTaskStk[STAT_TASK_STK_SIZE];
#endif

#if (OS_CFG_TMR_EN == DEF_ENABLED)
static  CPU_STK  TimerTaskStk[TIMER_TASK_STK_SIZE];
#endif

static  CPU_STK  ISRStack[ISR_STK_SIZE];

#if (MSG_POOL_ELEMENTS > 0)
static  MEM_SEG    MsgPoolMemSeg;
static  CPU_INT08U MsgPoolMem[MSG_POOL_SIZE];
#endif

const   OS_INIT_CFG             OS_InitCfg          = OS_INIT_CFG_APP;
const   COMMON_INIT_CFG         Common_InitCfg      = COMMON_INIT_CFG_APP;
const   PLATFORM_MGR_INIT_CFG   PlatformMgr_InitCfg = PLATFORM_MGR_INIT_CFG_APP;

The stack variables will only be created if the tasks are enabled in os_cfg.h. If the task is enabled, the size is pulled in from the configuration above. The ISR stack is always created because its needed in every Micrium OS project. The message pool is only created if it is needed.

The OS_INIT_CFG, COMMON_INIT_CFG and PLATFORM_MGR_INIT_CFG structs MUST be named OS_InitCfg, Common_InitCfg and PlatformMgr_InitCfg. This is due to the RTOS_CFG_EXTERNALIZE_OPTIONAL_CFG_EN define set in the rtos_cfg.h. Micrium OS uses variables by these names to initialize the modules and if they are not defined in the user application, there will be compilation errors as the internal default config has been removed by the define in rtos_cfg.h.

Inits in main() and includes

After setting up all of the necessary variables for the config structs, two more changes must be made. 

#include  

The ex_main.c file needs to have the platform manager header file added to its list of includes. A compilation error will occur without this extra include.

int  main (void)
{
    RTOS_ERR  err;

#if (MSG_POOL_ELEMENTS > 0)
    Mem_SegCreate(          "Msg Pool Mem",                     /* Create the Message Pool memory segment               */
    		                &MsgPoolMemSeg,
				  (CPU_ADDR)&MsgPoolMem,
				             MSG_POOL_SIZE,
				             LIB_MEM_PADDING_ALIGN_NONE,
				            &err);
    APP_RTOS_ASSERT_DBG((RTOS_ERR_CODE_GET(err) == RTOS_ERR_NONE), 1);
#endif

    ...
}

The last change that needs to be made to ex_main.c is the addition of a Memory Segment Create. The OS config only allocates space for a memory segment. When the application starts up, its necessary to make a call to Mem_SegCreate to create the memory segment BEFORE the OSInit call is made. OSInit uses the memory segment and if it has not been initialized the application will fail to run.  

Building the new Blink project and comparing results

After all of these changes have been made to the Micrium OS Blink project, the project can be built by right clicking on the project name and selecting Build Project as shown above. 

Default Micrium OS Blink project RAM/ROM usage

Micrium OS Blink project RAM/ROM usage after adding external configuration

After building the project the console window will show the final sizes for RAM and ROM. As seen in the images above, the RAM usage is reduced from 24KB to just under 19KB simply by moving the internal tasks from the heap to the external config instead. 

The default RAM usage in this project is rather high to begin with because it includes SEGGER's SystemView code and the application task stack size is very large for such a simple project (currently set to 512 stack units/2048 bytes). To further reduce RAM usage in this project its possible to:

• Disable internal tasks that are not needed via os_cfg.h.
• Disable SEGGER SystemView code via os_cfg.h and os_cfg_trace.h
• Shrink the Main Start Task Stack Size 
• Reuse CSTACK after the OS has started up

The ex_main.c file is attached to this post and feel free to ask any questions in the forum below.

This blog should serve as a guide to adding Micrium OS on a Flex Gecko and get at least one task running on the device.

I will now share with you my experience while going through this exercise.

Getting Started

I decided to perform a clean installation of Simplicity Studio in order to avoid conflicts inflicted by software updates over time. After installing the tool, before even attempting to add anything, I first had to make sure that I had the necessary SDKs. Here's what I installed:

• 32-bit MCU SDK - 5.5.0.0
• Micrium OS - 5.4.0
• Flex SDK - 2.3.0.0

I then mounted a Flex Gecko, EFR32FG12 in my case, onto a Wireless Started Kit Mainboard (BRD4001A). After that, I connected it to the PC using the provided USB cable.

Simplicity Studio recognized a Flex Gecko connected to a WSTK and displayed the link to examples from the Flex SDK (see Figure 1).

 

Loading a Basic Flex SDK Example

As a starting point, I decided to go with the "RAIL: Simple RAIL without HAL" example from the Flex SDK.

You can find this by expanding the list of projects under the "Silicon Labs Flex SDK Examples" link:

 

Then find and click the example shown in Figure 3 to add it to your workspace:

 

After the example loads on your workspace, you might get a notice as shown in Figure 4. Just click "OK".

 

You will then be presented with simple_rail_without_hal.isc opened where you can configure RAIL. In my case, I left everything in its default values and simply clicked on "Generate" as shown in Figure 5.

 

At this point, you should now be set with a basic Flex Gecko example that builds and runs. However, I did find that the default project settings have compiler optimization set to "Optimize for size (-Os)" which will eventually make debugging the project rather difficult. Therefore, I switched optimizations to "None (-O0)".

 

Adding Micrium OS to the Workspace

Now that you have a basic Flex Gecko example that builds and runs, let's go ahead and start adding the Micrium OS source files into the workspace.

First, locate the Micrium OS directory, it should be in:

C:\SiliconLabs\SimplicityStudio\v4\developer\sdks\gecko_sdk_suite\v2.3\platform\micrium_os

 

Now drag and drop the "micrium_os" folder into your project (simple_rail_without_hal) in Simplicity Studio. When doing this, make sure that you have "Copy files and folders" selected before clicking "OK" as shown in Figure 7.

 

You will then have to remove all the unnecessary files that get added with Micrium OS (this was tedious).

Here's how your "micrium_os" folder should end up looking:

 

Finally, the compiler needs to know where to look for the header files so we have to add two compiler include paths to the project settings:

"${workspace_loc:/${ProjName}/micrium_os}"
"${workspace_loc:/${ProjName}/micrium_os/cfg}"

 

Configuring Micrium OS

Now that you have Micrium OS as part of your project, let's go ahead and make some minor adjustments to the default Micrium OS configuration.

1. Open rtos_description.h located in your project under "micrium_os/cfg/"
2. Replace the contents of the file with one below:

/*
*********************************************************************************************************
*                                             EXAMPLE CODE
*********************************************************************************************************
* Licensing:
*   The licensor of this EXAMPLE CODE is Silicon Laboratories Inc.
*
*   Silicon Laboratories Inc. grants you a personal, worldwide, royalty-free, fully paid-up license to
*   use, copy, modify and distribute the EXAMPLE CODE software, or portions thereof, in any of your
*   products.
*
*   Your use of this EXAMPLE CODE is at your own risk. This EXAMPLE CODE does not come with any
*   warranties, and the licensor disclaims all implied warranties concerning performance, accuracy,
*   non-infringement, merchantability and fitness for your application.
*
*   The EXAMPLE CODE is provided "AS IS" and does not come with any support.
*
*   You can find user manuals, API references, release notes and more at: https://doc.micrium.com
*
*   You can contact us at: https://www.micrium.com
*********************************************************************************************************
*/

/*
*********************************************************************************************************
*
*                                           RTOS DESCRIPTION
*
*                                      CONFIGURATION TEMPLATE FILE
*
* File : rtos_description.h
*********************************************************************************************************
*/

/*
*********************************************************************************************************
*********************************************************************************************************
*                                               MODULE
*********************************************************************************************************
*********************************************************************************************************
*/

#ifndef  _RTOS_DESCRIPTION_H_
#define  _RTOS_DESCRIPTION_H_


/*
*********************************************************************************************************
*********************************************************************************************************
*                                             INCLUDE FILES
*********************************************************************************************************
*********************************************************************************************************
*/

#include  <common/include/rtos_opt_def.h>


/*
*********************************************************************************************************
*********************************************************************************************************
*                                       ENVIRONMENT DESCRIPTION
*********************************************************************************************************
*********************************************************************************************************
*/

#define  RTOS_CPU_SEL                                       RTOS_CPU_SEL_ARM_V7_M

#define  RTOS_TOOLCHAIN_SEL                                 RTOS_TOOLCHAIN_GNU

#define  RTOS_INT_CONTROLLER_SEL                            RTOS_INT_CONTROLLER_ARMV7_M


/*
*********************************************************************************************************
*********************************************************************************************************
*                                       RTOS MODULES DESCRIPTION
*********************************************************************************************************
*********************************************************************************************************
*/

                                                                /* ---------------------- KERNEL ---------------------- */
#define  RTOS_MODULE_KERNEL_AVAIL


/*
*********************************************************************************************************
*********************************************************************************************************
*                                             MODULE END
*********************************************************************************************************
*********************************************************************************************************
*/

#endif                                                          /* End of rtos_description.h module include.            */

 

Modifying main.c

We'll be making modifications to the default main.c generated by the "RAIL: Simple RAIL without HAL" example.

Micrium OS requires the following include paths in main.c so go ahead and add them as shown below:

#include  <cpu/include/cpu.h>
#include  <kernel/include/os.h>
#include  <common/include/common.h>
#include  <common/include/rtos_utils.h>
#include  <common/source/kal/kal_priv.h>  /* Private file, use should be limited */

 

We'll be modifying main.c to initialize Micrium OS and create a start task. For that, you'll need to specify a task stack size and a priority. We typically do this by defining them as constants and passing those in the call to OSTaskCreate().

The start task also requires its own Stack and Task Control Block (OS_TCB) as well as its function prototype. Therefore, add the following to main.c:

#define  START_TASK_PRIO              21u
#define  START_TASK_STK_SIZE         512u
                                                                
static  CPU_STK  StartTaskStk[START_TASK_STK_SIZE];  /* Start Task Stack. */
static  OS_TCB   StartTaskTCB;                       /* Start Task TCB.   */

static  void  StartTask (void  *p_arg);

 

Here's the body of the StartTask function where the kernel tick gets initialize and as well as the Common module. Note that the function includes an infinite loop at the end with a time delay of 1 second. This is done to yield CPU time to other tasks that are or will eventually run on your system. You can copy and paste the following in your main.c:

static  void  StartTask (void  *p_arg)
{
  RTOS_ERR    err;
  CPU_INT32U  cpu_freq;
  CPU_INT32U  cnts;

  /* Prevent compiler warning. */
  PP_UNUSED_PARAM(p_arg);                                     

  /* Determine SysTick reference freq. */
  cpu_freq =  SystemCoreClockGet();
  /* Cal. SysTick counts between two OS tick interrupts. */
  cnts     = (cpu_freq / (CPU_INT32U)KAL_TickRateGet());

  /* Init uC/OS periodic time src (SysTick). */
  OS_CPU_SysTickInit(cnts);

#if (OS_CFG_STAT_TASK_EN == DEF_ENABLED)
  /* Initialize CPU Usage. */
  OSStatTaskCPUUsageInit(&err);
  /* Check error code. */
  APP_RTOS_ASSERT_DBG((RTOS_ERR_CODE_GET(err) == RTOS_ERR_NONE), ;);
#endif

#ifdef CPU_CFG_INT_DIS_MEAS_EN
  /* Initialize interrupts disabled measurement. */
  CPU_IntDisMeasMaxCurReset();
#endif

  /* Call common module initialization example. */
  Common_Init(&err);
  APP_RTOS_ASSERT_CRITICAL(err.Code == RTOS_ERR_NONE, ;);

  while (DEF_ON) {
	  /* Delay Start Task execution for 1000 OS Ticks from now. */
      OSTimeDly(1000, OS_OPT_TIME_DLY, &err);
      /* Check error code. */
      APP_RTOS_ASSERT_DBG((RTOS_ERR_CODE_GET(err) == RTOS_ERR_NONE), ;);
  }
}

 

Finally, let's modify main() to initialize the CPU, re-assign interrupt handlers as kernel-aware, initialize the kernel, create the Start Task, and start the OS. Here's how main() should end up looking:

int main(void)
{
  uint32_t vtorAddress = SCB->VTOR;
  CPU_FNCT_VOID * vtor = (CPU_FNCT_VOID *)vtorAddress;
  RTOS_ERR  err;

  CPU_Init();

  /* Re-assign previous interrupt handlers as kernel-aware */
  for (uint32_t i = CPU_INT_EXT0; i < CPU_INT_EXT0 + EXT_IRQ_COUNT; i++) {
    CPU_IntSrcHandlerSetKA(i, vtor[i]);
  }

  /* Initialize the Kernel. */
  OSInit(&err);
  /* Check error code. */
  APP_RTOS_ASSERT_DBG((RTOS_ERR_CODE_GET(err) == RTOS_ERR_NONE), 1);

  /* Create the Start Task. */
  OSTaskCreate(&StartTaskTCB,
               "Start Task",
                StartTask,
                DEF_NULL,
                START_TASK_PRIO,
               &StartTaskStk[0],
               (START_TASK_STK_SIZE / 10u),
                START_TASK_STK_SIZE,
                0u,
                0u,
                DEF_NULL,
               (OS_OPT_TASK_STK_CLR),
               &err);
  /* Check error code. */
  APP_RTOS_ASSERT_DBG((RTOS_ERR_CODE_GET(err) == RTOS_ERR_NONE), 1);

  /* Start the kernel. */
  OSStart(&err);
  /* Check error code. */
  APP_RTOS_ASSERT_DBG((RTOS_ERR_CODE_GET(err) == RTOS_ERR_NONE), 1);

  return (1);
}

 

You are now set to build and run the project. You can put a breakpoint on the Start Task inside the while loop and notice that you'll be hitting that every second (or as specified by the delay you configure in OSTimeDly()).

Please do understand that this is a very basic guide that resembles more a hack rather than an official solution from Silicon Labs. Hopefully, Micrium OS can be part of the Flex SDK in the future, but in the meantime, this is a start.

I hope this was useful to you. Feel free to post any comments or questions regarding this blog post.

The Silicon Labs Dynamic Multiprotocol allows you to support multiple wireless protocols on a single chip.

This technology time-slices the radio and rapidly changes configurations to enable different wireless protocols to operate reliably at the same time. 

The technology leverages Micrium OS Kernel to run each wireless stack as a separate RTOS task.

You are probably aware of the multiple benefits of SystemView; a tool to record and analyze the Micrium OS Kernel events in real-time.

To enable SystemView, Simplicity Studio offers this utility that inserts the required C files and configures the project include paths all by the press of a button. It sounds great, except that it is usually broken by constant changes in the different SDKs from Silicon Labs.

In this blog, I'm gonna describe how to add SystemView to your DMP project manually, for those situations in which fancy tools just won't work.

 

Inserting the SystemView Recorder Files to your DMP Project

Right-click over the project name to open the context menu and select the options New -> Folder

Click the button Advanced >>  select the option Link to alternate location (Linked Folder) and enter the following path:

STUDIO_SDK_LOC\util\third_party\segger\systemview

 

As shown in the image below:

 

 

Inserting the Include Paths in your Compiler Configuration

Right-click over the project name to open the context menu and select the option Properties.

Select the option C/C++ General > Paths and Symbols and add the following include paths to all Languages and Configurations: 

${StudioSdkPath}/util/third_party/segger/systemview/Config
${StudioSdkPath}/util/third_party/segger/systemview/SEGGER
${StudioSdkPath}/util/third_party/segger/systemview/Sample/MicriumOSKernel
${StudioSdkPath}/util/third_party/segger/systemview/Sample/MicriumOSKernel/Config

 

 

Resolving a couple of conflicts by excluding some C Files from compilation

Locate the file SEGGER_SYSVIEW_Config_MicriumOSKernel.c in the Project Explorer at dev-cfg > source

Right click over the file SEGGER_SYSVIEW_Config_MicriumOSKernel.c to open the context menu and select the option Properties.

Select the option C/C++ Build and exclude this file from compilation by selecting the checkbox Exclude resource from build.

Similarly, locate the file SEGGER_RTT.c in the Project Explorer at debug-basic-library > EFR32

Right click over the file SEGGER_RTT.c to open the context menu and select the option Properties.

Select the option C/C++ Build and exclude this file from compilation by selecting the checkbox Exclude resource from build.

 

 

Enabling the Trace Recorder

Open the file os_cfg.h located at the following path:

STUDIO_SDK_LOC\protocol\zigbee\app\framework\plugin-soc\micrium-rtos\config\os_cfg.h

 

Locate and set the macro OS_CFG_TRACE_EN to DEF_ENABLED

 

 

Finding the memory address of the RTT block

Re-compile your project and launch a Debug Session.

Click the button Probe located on the top toolbar of Simplicity Studio.

Once Probe is opened, type in the keyword _RTT in the Symbol Browser panel in Probe (at the bottom of the application) and make a note of the memory address as illustrated in the image below:

 

 

Starting a Recording

The SystemView host application is available from SEGGER.

Once you have the application installed on your computer, start SystemView.

Press F5 to start a recording.

Select the option Address for the RTT Control Block Detection and enter the address you found with Probe as shown below:

 

It may be that as the DMP SDK and/or Simplicity Studio evolve, the tool to insert SystemView automatically finally works. I will keep checking if that's the case and I will delete this blog if it's no longer relevant. In the meantime, I hope it will help someone.

 

Disclaimer: The views, thoughts, and opinions expressed in this blog belong solely to the author, and not necessarily to Silicon Labs.

 

Almost all of Silicon Labs Starter/Development Kits include an onboard J-Link debugger, which is great to not only debug and flash your embedded application, but also to run SystemView.

SystemView as you probably know is the tool to record and analyze your Micrium OS Kernel events in real time.

However, the onboard J-Link can be slow depending on the rate of kernel events that your embedded application is creating. Overflow events occur when the SystemView buffer on your embedded target is full.

In this blog I'm gonna discuss the basic steps to prevent overflows and then I will describe the ultimate way to prevent overflows.

 

Steps to Prevent Overflows

1. Increase the buffer size to store the events:

Open the configuration file SEGGER_SYSVIEW_Conf.h and set the buffer size to 4096 as shown below:

#define SEGGER_SYSVIEW_RTT_BUFFER_SIZE           4096

 

2. In case you are running Simplicity Studio, close Simplicity Studio and let SystemView run by itself.

 

3. In case you are running Probe, close Probe and let SystemView run by itself.

 

4. Open the configuration file os_cfg_trace.h and decrease the number of events by disabling the following features:

#define  OS_CFG_TRACE_API_ENTER_EN               DEF_DISABLED

#define  OS_CFG_TRACE_API_EXIT_EN                DEF_DISABLED

 

5. If you are still having overflows after making the changes above, then the ultimate way to prevent overflows is to buy a much faster External J-Link from SEGGER: https://www.segger.com/products/debug-probes/j-link/

Most of our Starter Kits have a Debug Connector that you can use to connect the external J-Link. 

The following section describes how to connect your external J-Link to a Silicon Labs Starter Kit.

 

Connecting your External J-Link

1. First you need to configure your Starter Kit to reroute the debugging circuitry to the external debug connector. 

Open Simplicity Studio, select your Starter Kit, locate the section Debug Mode: MCU and then press the link Change as shown in the image below:

 

2. You may be asked to download an adapter firmware image. If so, press the button Yes.

 

3. The default Debug Mode is called MCU which means that your debugger is the Onboard J-Link.

 

4. Select from the drop-down the option IN which means that your debugger is an External J-Link as shown in the image below:

 

5. Connect your external J-Link to the debug connector on your Silicon Labs Starter Kit.

Depending on your kit, it may be one of the ones shown below.

The J-Link 19-pin 0.05" Cortex-M Debug Connector shown in Figure 3 may require a J-Link 19-pin Cortex-M Adapter available from SEGGER.

 

On the other hand, the standard 20-pin 0.1" JTAG Debug Connector shown in Figure 4 does not require any adapters and can be connected directly to your external J-Link.

 

For more information on how to configure your Starter Kit in the appropriate debugging mode, please consult your Starter Kit's User's Guide, the section On-Board Debugger, Debug Modes.

 

Related Links:

SystemView Installer: https://www.segger.com/downloads/free-utilities/#SystemView

SystemView User's Manual: https://www.segger.com/downloads/free-utilities/#Manuals

J-Link Debug Probes: https://www.segger.com/products/debug-probes/j-link/

J-Link 19-pin Cortex-M Adapter: https://www.segger.com/products/debug-probes/j-link/accessories/adapters/19-pin-cortex-m-adapter/

 

Whether you are currently running your embedded application on Silicon Labs hardware or other semiconductor, the migration path is the same as illustrated in Figure 1.

You should start from a working Micrium OS example and then move your embedded application over to the example project.

 

Once you move your embedded application to the Micrium OS baseline example project, you need to change the code that calls the FreeRTOS API.

The purpose of the attached PDF document is to describe the differences between the two kernels, offer plenty of side-by-side examples and mapping tables to help you in the process of migrating your embedded application.