This blog should serve as a guide to adding Micrium OS File System(NOR device) on a Flex Gecko and get at least the FS core initialized, perform low/high-level if the Storage device requires it and execute a simple read/write application.

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:

• Gecko SDK Suite - 2.5.3
• Micrium OS - 5.6.0
• Flex SDK - 2.5.3.0

I then mounted a Flex Gecko, EFR32FG13(BRD4255A) 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).

Figure 1 - Initial Setup Validation

Loading a Basic Flex SDK Example

As a starting point, I decided to go with the "Connect(Soc): Sensor" example from the Flex SDK.

You can find this by expanding the list of projects under the "Connect Examples" link:

Figure 2 - Flex SDK Examples Link

You will then be presented with sensor.isc opened where you can configure Sensor. Since we are adding Micrium OS to the example, let's click on the "Plugins" tab and select the "Micrium RTOS" check box and "Application Task (1)" as shown on Figure 3. Make sure to press 'CRTL + S' to save the modifications and then clicked on "Generate".

Figure 3 - Sensor Project Configuration

Click the 'OK' button on the Generation validation pop-up window.

Figure 4 - Generation validation

At this point, you should now be set with a 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)".

Figure 5 - Compiler Optimizations

Installing Micrium OS File System

Assuming your credentials have the right access permissions to install Micrium OS File System, you will need to click on the 'Help->Update Software' menu. The "Installation Manager" window should pop-up. Please select the "Package Manager" option as shown on Figure 6. If you are not sure your credentials have the proper access to Micrium OS File System, please contact our sales department.

Figure 6 - Installation Manager

On the "Package Manager" window select the 'SDKs' tab and Micrium OS as Categories, then click on the 'Install' button Figure 7. Close the window once the installation is completed.

Figure 7 - Package Manager

Adding Micrium OS File System to the Workspace

The BRD4255A board has a 8-Mbit Macronix MX25R8035F SPI flash; therefore, our workspace will have all the Micrium OS File System files required to run the NOR(MX25R8035F) device. Since we already generated a Flex Gecko example that builds and runs, let's go ahead and start adding the Micrium OS File System 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.5\platform\micrium_os

Right-click on the 'sensor' workspace and select 'Import->MCU project'.  Once the "Import Project" window pops-up, please select the 'More Import Options" as shown on Figure 8.

Figure 8 - Import Project

During the next window, select the "General->File System" import source and click next. At this point, we will be adding all the necessary Micrium OS File System files to the workspace.

Figure 9 - BSP file for the NOR-SPI device.

 

Figure 10 Micrium OS common files

 

Figure 11 Micrium OS drivers for NOR-SPI

 

Figure 12 Micrium OS File System

Adding Micrium OS FS Examples to the Workspace

Locate the Micrium OS examples directory, it should be in:

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

Make a copy of the "micrium_os_example" folder and place it in the directory where the sensor example was generated. In my case the sensor example workspace was generated at:

C:\Users\UserName\SimplicityStudio\v4_workspace\sensor

Once you place the folder in the sensor directory, make sure to delete the following folders and file:

canopen
common
cpu
io
kernel
net
uC-Probe
usb
ex_main.c

In addition, we need to add the following include path to the project

"${workspace_loc:/${ProjName}/micrium_os_example}"

 

Configuring Micrium OS  and File System

Now that you have Micrium OS and File System as part of your project, let's go ahead and make some minor adjustments to the default Micrium OS configuration. Start by expanding the Includes section in the Project Explorer panel, then expand the "protocol/flex/connect/plugins/micrium-rtos/config" folder as shown in Figure 13 and 14. The files we will be modifying are "common_cfg.h", "os_cfg.h", and "rtos_description", so please double-click on those to open it in the editor.

Figure 13 Project Explorer Sensor Includes section

 

Figure 14 Micrium OS configurations.

 

Let's start by modifying "rtos_description.h" by adding the following File System defines:

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

#define  RTOS_MODULE_KERNEL_AVAIL

                                                                /* ------------------- FILE SYSTEM -------------------- */
#define  RTOS_MODULE_FS_AVAIL
#define  RTOS_MODULE_FS_STORAGE_NOR_AVAIL

As soon as you try to edit the "rtos_description.h", you will be presented a Warning indicating you are editing an SDK file. Click on "Make a Copy", and choose the same option when modifying "common_cfg.h" and "os_cfg.h".

Figure 15 Warning

 

Modify the following defines in "os_cfg.h" file

#define  OS_CFG_MON_EN         DEF_ENABLED
#define  OS_CFG_TASK_Q_EN      DEF_ENABLED

 

Modify the following defines in "common_cfg.h" file

#define  LIB_MEM_CFG_STD_C_LIB_EN              DEF_DISABLED
#define  LIB_MEM_CFG_HEAP_SIZE                 32768uL

The value of LIB_MEM_CFG_HEAP_SIZE  is used by the FS stack and examples so the value will depend on your application.

It is time to add the File system configurations by locating the configuration templates at:

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

Make a copy of "fs_core_cfg.h" and "fs_storage_cfg.h" and place them in the external_copied_files folder in your sensor directory. In my case the location was at:

C:\Users\UserName\SimplicityStudio\v4_workspace\sensor\external_copied_files

Open "fs_storage_cfg.h" and modify the following

#define  FS_STORAGE_CFG_MEDIA_POLL_TASK_EN                  DEF_DISABLED

 

Initialize Micrium OS File System and Simple Demo.

The micrium_os_example folder provides examples for initializing the File System and executing a simple Read/Write demo; therefore, let's make additional modifications to the project,which will allow us to run FS and simple demo.

In the Project Explorer, locate the micrium_os_example folder and open ex_description.h. Add the following define:

/********************************************************************************************************
 ********************************************************************************************************
 *                                         EXAMPLES DESCRIPTION
 ********************************************************************************************************
 *******************************************************************************************************/

#define  EX_FS_INIT_AVAIL

 

Open ex_fs.c located at micrium_os_example/fs and modify the following defines.

#define  EX_CFG_FS_MEDIA_LOW_LEVEL_FMT_EN       DEF_ENABLED
#define  EX_CFG_FS_MEDIA_HIGH_LEVEL_FMT_EN      DEF_ENABLED

#define  EX_FS_MEM_SEG_LEN                      (1u * 1024u) 

We are modifying EX_FS_MEM_SEG_LEN due to memory reasons; however, the original value should be enough to run most of the examples.

 

Open ex_fs_file_rd_wr.c located at micrium_os_example/fs and modify the following function call in Ex_FS_FileRdWr()

  Ex_FS_FileRdWr_Exec(vol_handle,
                      "file-rdwr.txt",
                      512u,                                    // File size.
                      &err);

 

At this point, we are ready to modify the flex-callbacks.c file and add the FS initialization and demo. Please open the file and modify the emberAfPluginMicriumRtosAppTask1MainLoopCallback() function as shown below as well as the includes.

Figure 17 - flex-callbacks.c file

 

We need to add one minor modification to bsp_fs_nor_spi.c, so please open the file (Figure16).

Figure 16 BSP for FS-NOR_SPI

 

Modify bsp_fs_nor_spi.c dependencies section as shown below, but keep in mind that as soon as you try to edit the it, you will be presented a Warning indicating you are editing an SDK file. Click on "Make a Copy"

Figure 18 - bsp_fs_nor_spi.c file

The bsp_fs_nor_spi.c file is very important, since it will be here that you will need to modify SPI pin configurations for the specific NOR device on your board. For the BRD4255A board you do not need to do anything else since all the pin configurations have been implemented; however, if you are using a different board then make sure your schematics match the PIN configurations on this file.

At this point you should be able to compile and flash the board. The example is very simple, the FS performs a low/high level format on the NOR storage device, then it opens a file and does a write/read operation. As soon as it is done, you should see LED0 blinking on the board. Keep in mind the low/high level format takes a few seconds to complete.

 

Introduction

When it comes to IoT device management, over-the-air (OTA) firmware updates play a key role.

OTA enables product manufacturers to remotely update connected devices with bug fixes, feature enhancements and security patches.

If you are evaluating one of our EFM32 32-bit MCUs such as the one onboard the Giant Gecko GG11 Starter Kit (SLSTK3701A) and want to learn a simple way to enable OTA firmware updates then this blog will get you started by presenting the example illustrated in the following diagram:

 

• Figure 1-(1): The embedded application acts as an HTTP-client and will connect to your web server to send a GET request to download a firmware update file (myupgrade.gbl). 
• Figure 1-(2): Your server responds with the firmware update file (myupgrade.gbl)
• Figure 1-(3): Once the file myupgrade.gbl is downloaded, the embedded application will store it by using the bootloader interface API to reprogram the bootloader storage area.
• Figure 1-(4): The embedded application will use the bootloader interface API to validate the firmware update image and upgrade the current application.

There are several criteria for the firmware update image to be flashed:

• The file myupgrade.gbl needs to be valid. This is checked by the embedded application using the bootloader interface API. 
• The embedded application checks the version of the firmware update image stored in myupgrade.gbl. If the version of the embedded application is the same or older than the running application, the image file will not be flashed.

The bootloader storage area will be erased, and the embedded application will try to establish a new HTTP/HTTPS connection, if:

• The loaded file is not a valid .gbl image.
• The version of the image stored is the same or older than the running version.
• Anything goes wrong with the HTTP/HTTPS protocol.

 

Hardware Requirements

• EFM32 Giant Gecko GG11 Starter Kit SLSTK3701A
• Web Server to host the firmware update file

 

Software Requirements

• Simplicity Studio
• 32-bit MCU SDK
• Micrium OS Kernel
• Micrium OS Network

 

Getting Started

1. Order an EFM32 Giant Gecko GG11 Starter Kit SLSTK3701A from our website

 

2. Install Simplicity Studio

• Download and Install the latest version of Simplicity Studio from our website at: http://www.silabs.com/simplicity-studio
• Download the software and follow the installation instructions.
• When asked to sign-in, enter your Silicon Labs username and password. Sign up for a new account if you don’t already have one. This is required to gain access to all of the software components.
• After signing in, register your kit with Simplicity Studio. If the kit is not registered, Simplicity Studio will only enable access to the Micrium Kernel; however, if the kit is registered, Simplicity Studio will enable access to all the other applicable Micrium components as well. The license number is on the box of the kit.

 

3. Connect the board as shown in the image below:

 

4. Open Simplicity Studio, from the Launcher perspective, select the example named SLSTK3701A_micriumos_httpcloader as shown below:

 

5. Open the file httpclient.c located in the /src folder in the Project Explorer and enter the full URL where you plan to host the firmware upgrade image:

#define  FULL_URL   "http://mywebserver.com/myupgrade.gbl"

 

If your webserver is secured (i.e. https) then this demo includes mbedTLS. Simply make sure that the certificate required by your website is defined in SSL_ROOT_CA[] in the file ssl_certificates.c located in the /src folder of the Project Explorer.

You may also have to tweak the number of bits and bytes that match your website's certificates by setting the proper sizes in MBEDTLS_ECP_MAX_BITS and MBEDTLS_MPI_MAX_SIZE in the configuration file config-ssl-
httpcloader.h located in C:\SiliconLabs\SimplicityStudio\v4\developer\sdks\gecko_sdk_suite\v2.5\app\mcu_example\SLSTK3701A_EFM32GG11\micriumos_httpcloader\config-ssl-httpcloader.h

#define MBEDTLS_MPI_MAX_SIZE   256
#define MBEDTLS_ECP_MAX_BITS   384

 

6. Open the file application_properties.c in the /src folder of the Project Explorer and set the version number of the embedded application to 2 to simulate a firmware upgrade:

#define APP_PROPERTIES_VERSION 2

 

7. Build the project

 

8. Generate the firmware upgrade file myupgrade.gbl by opening the utility Simplicity Commander located at C:\SiliconLabs\SimplicityStudio\v4\developer\adapter_packs\commander and by providing the path to your binary file .s37 to a command line similar to this:

commander.exe gbl create myupgrade.gbl --app "C:\Users\[YourUsername]\SimplicityStudio\v4_workspace\SLSTK3701A_micriumos_httpcloader\GNU ARM v7.2.1 - Debug\SLSTK3701A_micriumos_httpcloader.s37"

 

 

9. Upload the file myupgrade.gbl to your web server

 

10. Open the file application_properties.c in the /src folder of the Project Explorer and set the version number of the embedded application back to 1:

#define APP_PROPERTIES_VERSION 1

 

11. Build the project again

 

12. Connect the starter kit as previously shown in Figure 2

 

13. Open Device Manager in Windows to find out the COM Port number of the USB device listed as J-Link CDC UART Port

 

14. Open a Serial Console application such as PuTTY to see the debug messages during run time

 

15. Select the item J-Link Silicon Labs from the list of Debug Adapters, right-click to open the context menu and select the option Upload Application... as shown below:

 

16. In the field Application Image Path, select the file SLSTK3701A_micriumos_httpcloader.s37 that you just built by browsing to the workspace folder where you have your project, a path similar to the following:

C:\Users\[YourUsername]\SimplicityStudio\v4_workspace\SLSTK3701A_micriumos_httpcloader\GNU ARM v7.2.1 - Debug\SLSTK3701A_micriumos_httpcloader.s37

 

Tick the checkbox to Upload a Bootloader image and select the bootloader that comes with the example by browsing to the file bootloader-storage-internal-single-combined.s37 in a path similar to this:

C:\SiliconLabs\SimplicityStudio\v4\developer\sdks\gecko_sdk_suite\v2.5\app\mcu_example\SLSTK3701A_EFM32GG11\micriumos_httpcloader\bootloader-storage-internal-single-combined.s37

 

 

17. Press the button Ok to flash both images. The bootloader image will be flashed in a reserved area of Flash and from this point forward you can simply Launch a Debug Session from Simplicity Studio to program the device with a different application image as the bootloader image will be stored in a reserved area of Flash that won't be deleted unless you overwrite it with this tool or from the command line with Simplicity Commander.

 

18. Watch the serial terminal as the embedded application starts the Ethernet interface, connects to your website to download the file myupgrade.gbl and reboots on the new upgraded embedded application. 

 

 

Further Reading

The firmware update situation described in this example assume no authentication and no encryption of the firmware update file. However, these features along with secure boot are supported by our system but it is beyond the scope of this blog.

To sign and encrypt a firmware update file, you can use Simplicity Commander as follows:

commander.exe gbl create --app --bootloader --metadata --compress --encrypt --sign --force

 

For more information on how to use Simplicity Commander see the section GBL Commands on Page 34 of the following document: 

• UG162: Simplicity Commander Reference Guide: 

https://www.silabs.com/documents/public/user-guides/ug162-simplicity-commander-reference-guide.pdf

 

For more information on the Gecko Bootloader see the following documents: 

• UG266: Gecko Bootloader User's Guide:

https://www.silabs.com/documents/public/user-guides/ug266-gecko-bootloader-user-guide.pdf

• UG103.6: Bootloader Fundamentals:

https://www.silabs.com/documents/public/user-guides/ug103-06-fundamentals-bootloading.pdf

 

 

 

The objective of this blog is to show you the steps necessary to use an existing Micrium OS USBD example and add a different class and demo using the EFM32GG11.

Baseline Project

Since the Gecko SDK currently ships with a ‘micriumos_usbdhidmouse’ project for the SLSTK3701A_EFM32GG11 board, we can make a copy of it and rename it ‘micriumos_usbdvendor’. The convenience of making a copy of the project is to modify it according to our needs without breaking the Gecko SDK default projects. Start by locating the ‘micriumos_usbdhidmouse’ folder in your Simplicity Studio installation. The project location is at ‘C:\SiliconLabs\SimplicityStudio\v4\developer\sdks\gecko_sdk_suite\v2.5\app\mcu_example\SLSTK3701A_EFM32GG11’

Once you found the folder, make a copy of it and rename it ‘micriumos_usbdvendor’. Please make sure to keep the new folder at the same path location of the original. Locate the ‘SLSTK3701A_micriumos_usbdhidmouse.slsproj’  file inside your New Folder  ‘micriumos_usbdvendor\SimplicityStudio’ and rename it ‘SLSTK3701A_micriumos_usbdvendor.slsproj’ 

We will be adding our new workspace, so launch Simplicity Studio and connect the SLSTK3701A_EFM32GG11 board to the PC.

Add workspace by right-clicking anywhere inside the Project Explorer box and Select Import>MCU Project

 

Use the Browse button to locate the ‘SLSTK3701A_micriumos_usbdvendor.slsproj’ and click Next>

File Location: `C:\SiliconLabs\SimplicityStudio\v4\developer\sdks\gecko_sdk_suite\v2.5\app\mcu_example\SLSTK3701A_EFM32GG11\micriumos_usbdvendor\SimplicityStudio`

 

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

 

You can either change the name of the project or keep the default, then click Finish.

 

Configuration Files

 We will now need to modify the project configuration files to include Micrium OS USBD Vendor class as part of our build. 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 the rtos_configuration.h to open it in the editor.

 

As soon as you try to edit the rtos_description.h, you will be presented a Warning indicating you are editing an SDK file. Click on Edit in SDK.

Add the following #define in rtos_description.h to indicate Micrium OS that you want to use VENDOR class.

#define  RTOS_MODULE_USB_DEV_VENDOR_AVAIL

Remove the following #define in rtos_decription.h

#define  RTOS_MODULE_USB_DEV_HID_AVAIL

 

Tell Micrium OS you want to use the USBD VENDOR demo by modifying ex_description.h. Expand the Includes section in the Project Explorer panel, then expand the project folder as shown in the image below. After that, double-click on the ex_description.h to open it in the editor.

As soon as you try to edit the ex_description.h, you will be presented a Warning indicating you are editing an SDK file. Click on Edit in SDK.

Remove the following #define in ex_description.h

#define RTOS_MODULE_USB_DEV_HID_AVAIL

Add the following #define in ex_description.h  to indicate Micrium OS you want to use VENDOR class.

#define  RTOS_MODULE_USB_DEV_VENDOR_AVAIL

 

Adding USBD Class and Demo

Expand the src section in the Project Explorer panel and remove the ‘ex_usbd_hid_mouse.c’ linked file.

 

Select Import > MCU Project by right-clicking on src section as shown on image below

 

Choose ‘More Import Options…’  and select File System  on the next window that pops-up as shown on the images below

 

Add ‘ex_usbd_vendor_loopback.c’ example as shown on image below, and click Finish.

File location: 'C:\SiliconLabs\SimplicityStudio\v4\developer\sdks\gecko_sdk_suite\v2.5\app\micrium_os_example\usb\device\all'

 

Expand the usb>source>device>class section in the Project Explorer  panel and right-click on class. Select Import > MCU Project  and add the USBD VENDOR class file as shown on images below

 

Use the Browse button to locate the  VENDOR class files to be added as shown below.

File location:  'C:\SiliconLabs\SimplicityStudio\v4\developer\sdks\gecko_sdk_suite\v2.5\platform\micrium_os\usb\source\device\class'

 

Running the Example

You can now build your application and flash it on the board. Once the application starts running, you should see LED0 on the board blinking which means all the initialization was done correctly; therefore, we can now test the USBD VENDOR demo.

Use a Micro-USB B cable to connect the PC to the EFM32GG11 board. As soon as you connect it, Windows will enumerate the device and display it in 'Universal Serial Bus Devices' as shown in the image below. 

Execute the Windows USB application provided in the attachment (Located at 'App\Host\OS\Windows\Vendor\Visual Studio 2010\exe\x86') and provide the number of transfers.

 

An important aspect of any IoT device is how secure the device is when it communicates with other devices, gateways or the cloud. It is common for developers to secure communications such as TCP/IP connections, Bluetooth or Zigbee. However, if a microcontroller sends sensitive information over a simple interface such as a UART to another microcontroller, it is important to realize that data should also be secured to prevent someone from snooping the UART line.

Silicon Labs offers a hardware CRYPTO module that provides an efficient acceleration of common cryptographic operations and allows these to be used efficiently with low CPU overhead. In addition to the CRYPTO module, Silicon Labs also provides a mbed TLS library to integrate with mbed TLS to allow it to take advantage of the CRYPTO module acceleration.

To use mbed TLS in a Micrium OS based application, first the developer must understand how the mbed TLS library will be used in the application. By default, mbed TLS is intended to be used in a single threaded/bare metal application or used in only a single thread of an RTOS application. For a Micrium OS application, this means if there will only be one task calling mbed TLS functions then no special modifications to the config file are necessary. If mbed TLS will be called from multiple tasks, for example a Bluetooth project that has a UART to communicate to another microcontroller, then a few modifications need to be made to the mbed TLS config header.

The following instructions will show you how to enable thread protection in mbed TLS for a Micrium OS Blink project on the Giant Gecko Series 1 (SLSTK3701A). If you have any difficulty getting the project set up, a .sls file is attached to this post for you to download. If you need further information on the SiLabs’ mbed TLS library, refer to Application Node AN0955.

Open Simplicity Studio and with your GG11 plugged in, select the board under debug adapters and then expand the Software Examples. Select the SLSTK3701A_micriumos_blink project and jump to the Simplicity IDE. 

First, mbed TLS must be added to the project as its not already included. You can either download mbed TLS from https://tls.mbed.org or you can grab a copy from your install of Simplicity Studio from: Simplicity Studio install location -> Eclipse -> developer -> sdks -> gecko_sdk_suite -> v2.4 -> util -> third_party -> mbedtls. Place those files into the workspace folder for the SLSTK3701A_micriumos_blink.

Once you have mbed TLS added to the project, you need to add the SiLabs library for mbed TLS to the workspace for SLSTK3701A_micriumos_blink. Under the Simplicity Studio install you can copy the sl_crypto folder and config folder from here: Eclipse -> developer -> sdks -> gecko_sdk_suite -> v2.4 -> util -> third_party -> mbedtls.

After adding the folders to the workspace similar to the image above, include paths need to be added to the project. Under the project properties, go to C/C++ Build -> Settings -> GNU ARM C Compiler -> Includes. 

Paths need to be added for the config directory, include directory and the sl_crypto directory. After adding those paths, remain in the project settings and go to Symbols under GNU ARM C Compiler.

At this point, mbed TLS has been added to the project, but it is only set to run in its default configuration. This means it won’t take advantage of the CRYPTO module acceleration and it won’t work from multiple threads. To fix that, add a new symbol that contains the following: MBEDTLS_CONFIG_FILE="config-sl-crypto-all-acceleration.h" then click OK. This will tell all mbed TLS files to look at the new config file, rather than the default config.h file.

Open up the config-sl-crypto-all-acceleration.h under the config directory. This is the default config file for enabling all hardware accelerations supported by SiLabs’ mbed TLS library. Add the following code to the header file to enable threading and remove a requirement for network sockets (unless you plan to use them). This code must be placed directly below the #include “mbedtls/config.h”.

/* Include the default mbed TLS config file */
#include "mbedtls/config.h"

/* Add Micrium OS support */
#define MBEDTLS_THREADING_ALT
#define MBEDTLS_THREADING_C
#define MBEDTLS_MICRIUM
#undef MBEDTLS_NET_C

#undef MBEDTLS_TIMING_C

Finally, the last piece to enable Micrium OS support in mbed TLS is to initialize threading support before starting Micrium OS. In the file ex_main.c, place the following code in main() anytime after the OSInit() call and before OSStart(). This will initialize the necessary mutexes to provide the protection.

// Enable Micrium OS support
#if defined ( MBEDTLS_THREADING_C )
    THREADING_setup();
#endif

At this point, after the OSStart() call completes and multitasking has begun, any mbed TLS call can be made safely from any task in Micrium OS.

The objective of this blog is to show you the steps necessary to use an existing Micrium OS USBD example and add CDC-ACM class and demo using the EFM32GG11.

Baseline Project

Since the Gecko SDK currently ships with a ‘micriumos_usbdhidmouse’ project for the SLSTK3701A_EFM32GG11 board, we can make a copy of it and rename it ‘micriumos_usbdcdcacm’. The convenience of making a copy of the project is to modify it according to our needs without breaking the Gecko SDK default projects.

Start by locating the ‘micriumos_usbdhidmouse’ folder in your Simplicity Studio installation. The project location is at ‘C:\SiliconLabs\SimplicityStudio\v4\developer\sdks\gecko_sdk_suite\v2.4\app\mcu_example\SLSTK3701A_EFM32GG11’

Once you found the folder, make a copy of it and rename it ‘micriumos_usbdcdcacm’. Please make sure to keep the new folder at the same path location of the original.

Locate the ‘SLSTK3701A_micriumos_usbdhidmouse.slsproj’  file inside your New Folder  ‘micriumos_usbdcdcacm\SimplicityStudio’ and rename it ‘SLSTK3701A_micriumos_usbdcdcacm.slsproj’ 

We will be adding our new workspace, so launch Simplicity Studio and connect the SLSTK3701A_EFM32GG11 board to the PC.

Add workspace by right-clicking anywhere inside the Project Explorer box and Select Import > MCU Project

 

Use the Browse button to locate the ‘SLSTK3701A_micriumos_usbdcdcacm.slsproj’ and click Next>

File location: 'C:\SiliconLabs\SimplicityStudio\v4\developer\sdks\gecko_sdk_suite\v2.4\app\mcu_example\SLSTK3701A_EFM32GG11\micriumos_usbdcdcacm\SimplicityStudio'

 

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

 

You can either change the name of the project or keep the default, then click Finish.

 

Configuration Files

 We will now need to modify the project configuration files in order to include Micrium OS USBD CDC-ACM class as part of our build.

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 the rtos_configuration.h to open it in the editor.

 

As soon as you try to edit the rtos_description.h, you will be presented a Warning indicating you are editing an SDK file. Click on Edit in SDK.

Add the following #define in rtos_description.h to indicate Micrium OS that you want to use CDC ACM class.

#define  RTOS_MODULE_USB_DEV_ACM_AVAIL
#define  RTOS_MODULE_USB_DEV_CDC_AVAIL

Remove the following #define in rtos_decription.h

#define  RTOS_MODULE_USB_DEV_HID_AVAIL

 

Tell Micrium OS you want to use the USBD CDC-ACM demo by modifying ex_description.h. Expand the Includes section in the Project Explorer panel, then expand the project folder as shown in the image below. After that, double-click on the ex_description.h to open it in the editor.

As soon as you try to edit the ex_description.h, you will be presented a Warning indicating you are editing an SDK file. Click on Edit in SDK.

Remove the following #define in ex_decription.h

#define  RTOS_MODULE_USB_DEV_HID_AVAIL

Add the following #define in ex_description.h to indicate Micrium OS that you want to use CDC-ACM class.

#define  RTOS_MODULE_USB_DEV_ACM_AVAIL

 

Adding USBD Class and Demo

Expand the src section in the Project Explorer panel and remove the ‘ex_usbd_hid_mouse.c’ linked file.

 

Select Import > MCU Project by right-clicking on src section as shown on image below

 

Choose ‘More Import Options…’  and select File System  on the next window that pops-up as shown on the images below

 

Use Browse button and add ‘ex_usbd_cdc_acm_terminal.c’ example as shown on image below, and click Finish.

File location: `C:\SiliconLabs\SimplicityStudio\v4\developer\sdks\gecko_sdk_suite\v2.4\app\micrium_os_example\usb\device\all`

 

Expand the usb>source>device>class section in the Project Explorer  panel and right-click on class. Select Import > MCU Project  and add the USBD CDC ACM class file as shown on images below

 

Use the Browse button to locate the CDC-ACM files to be added as shown below.

File location: `C:\SiliconLabs\SimplicityStudio\v4\developer\sdks\gecko_sdk_suite\v2.4\platform\micrium_os\usb\source\device\class`

 

Running the Example

You can now build your application and flash it on the board. Once the application starts running, you should see LED0 on the board blinking which means all the initialization was done correctly; therefore, we can now test the USBD CDC-ACM demo.

Open Windows Device Manager and expand the 'Ports (COM & LPT)' section. 

Use a Micro-USB B cable to connect the PC to the EFM32GG11 board. As soon as you connect it, Windows will enumerate the device and display it in 'Ports (COM & LPT)' as shown in the image below. Keep in mind that Windows is the one assigning the port number (COM7)  to my device.

 

Once you know the serial port number, we can use any serial terminal application and  open a terminal window.  The images below shows the terminal configurations and the CDC-ACM demo output.

 

If you work with Micrium OS, chances are you will eventually encounter some macro prefixed with RTOS_ASSERT which traps your task in an infinite loop.  Micrium OS has two types of ASSERTs, Critical ASSERTs and Debugging ASSERTs. The former type of ASSERT is intended to catch severe errors which may prevent the system from functioning normally such as a module failing to initialize correctly. On the other hand, Debugging ASSERTs are used to catch ordinary errors returned from an API call so that they are found quickly while debugging. However, the question naturally arises: should my system crash because I passed a bad delay value to OSTimeDly?

 

There are a few options to customize how these conditions are handled in your system.

1. You can disable debugging ASSERTs, which will also disable error checking. This is recommended once the project is stable and ready for production.

2. You can force the ASSERTs to return a value, with some caveats.

In order to make these changes, you must modify this section of rtos_cfg.h.

 

Option 1 requires changing the MASK to RTOS_CFG_MODULE_NONE.

Option 2 requires modifying the DBG macro so that it returns the error value.

However, you must be careful not to use any ASSERT_DBG() macros at the top level of your task; you may unintentionally return from the task if you do so.

 

For more details on ASSERTs, please refer to the following pages:

https://doc.micrium.com/display/OSUM50500/Micrium+OS+Asserts+Programming+Guide

https://doc.micrium.com/display/OSUM50500/RTOS+Compile-Time+Configuration

 

Background

The Micrium OS Examples in Simplicity Studio are very easy to access: You connect your Starter Kit and Simplicity Studio will display the list of examples as shown below:

 

For more information on how to access the Micrium OS Examples from Simplicity Studio you can see this document:

https://www.silabs.com/documents/public/training/wireless/micrium-os-examples.pdf

 

 

Revealing the 57 Hidden Gems

In this blog, I’m going to show you how to access the additional Micrium OS Examples that are not available from Simplicity Studio's Launcher Perspective.

There are 57 examples that demonstrate how to initialize the Micrium OS modules to perform the most basic operations:

Micrium OS Module		Example
CANopen		CANopen Module Initialization Example
		CANopen Node Start Example
		CANopen Object Dictionary Read/Write Example
File System		File System Module Initialization Example
		File Read/Write Example
		File Read/Write with Posix API Example
		File Multi-Descriptors Example
		Entry Path Example
		Block Device Read/Write Example
		Media Polling Example
Network	FTP Client	Send Data from a buffer to a file on an FTP Server
		Upload a file to an FTP Server
		Receive a file into a buffer
		Download a file from an FTP server
	HTTP Client	HTTP Client Initialization Example
		HTTP Client GET Request Examples
		HTTP Client POST Request Examples
		HTTP Client PUT Request Examples
		HTTP Client Persistent Connection Examples
		HTTP Client Multi-connection Examples
	HTTP Server	HTTP Server Initialization Example
		Simple Server That Uses No File System
		Basic Server That Uses the HTTP Static File System
		Basic Server That Uses Micrium OS File System
		Server That Handles REST Requests
		Server That Handles Webpages, REST Requests and Authentication Support
		Basic Secure Server That Uses SSL-TLS and the HTTP Static File System
	IPerf	IPerf Initialization Example
	MQTT Client	MQTT Client Initialization Example
		MQTT Client Connect Example
		MQTT Client Publish Example
		MQTT Client Subscribe Example
		MQTT Client Echo Example
	Network Core	Network Module(s) Initialization Example
		Network Core Initialization Example
		Start Network Interface(s) Example
	SMTP Client	SMTP Client Initialization Example
		SMTP Client Send Email Example
	SNTP Client	SNTP Client Initialization Example
		Basic SNTP Current Time Retrieve
	Telnet Server	Telnet Server Initialization Example
		Telnet Server Instance Example
	TFTP Client	Download and Upload a File to a TFTP Server
USB Device	Audio Class	USB Device Audio Class Loopback Example
	CDC ACM Class	USB Device CDC ACM Class Terminal Example
	CDC EEM Class	USB Device CDC EEM Class Example
	USB Device Core	USB Device Core Initialization Example
	HID Class	USB Device HID Class Mouse Example
	MSC Class	USB Device MSC Class Ramdisk LUN Example
		USB Device MSC Class Ramdisk Shared Example
	Vendor Class	USB Device Vendor Class Loopback Example
USB Host	Android Accessory Class	USB Host Android Accessory Class Example
	CDC ACM Class	USB Host CDC ACM Class Example
	USB Host Core	USB Host Module Simple Initialization Example
		Simple Device Port Operation Example
	MSC Class	USB Host MSC Class Example
	USB-to-Serial Class	USB Host USB-to-Serial Class Example
Table 1. The Hidden Micrium OS Examples

 

 

How to run the hidden Micrium OS Examples

The process of including, configuring and initializing the examples is the same for all the examples and can be summarized as follows:

Start off with one of the examples available through Simplicity Studio by connecting your Kit and selecting an Example from the list as illustrated in Figure 1.

If the example project does not have the Micrium OS module files, then you need to include them by inserting in your project the folder located at ${StudioSdkPath}/platform/micrium_os/[module]/include and ${StudioSdkPath}/platform/micrium_os/[module]/source/[module] and configuring your compiler's include paths with the new paths.

Locate the header file rtos_description.h and insert the macro necessary to enable the module. For the full list of macros see this document.

Make sure you have in your project all the configuration files located in STUDIO_SDK_LOC\platform\micrium_os\cfg

Explore the examples listed in Table 1, select the one that you want and follow the corresponding hyperlink.

       The hyperlink will take you to the example's documentation which provides four things:

• Description: Brief description of the example
• Configuration: The name of the #define that needs to be defined in ex_description.h
• Location: The location of the files that need to be included
• API: The API that needs to be called from your application to start the example

Locate the header file ex_description.h and define the corresponding macro if necessary as described in the example's documentation section: Configuration.

Include in your Simplicity Studio project the required files as listed in the example's documentation section: Location. In this step you can either create a link to the original folder or make a copy of the files and place them in your own workspace directory.

Configure your compiler's include paths with the new paths where the header files are located.

Insert a #include in your application, of the header file where the API to start the example is declared and call the API from your application to get the example started as described in the example's documentation section: API.

 

 

Example

To illustrate the process, I'm going to provide an example where one is interested in running an HTTP server:

Connect the SLSTK3701A and select the example SLSTK3701A_micriumos_net from Simplicity Studio.

Inspect which modules are included in the project by looking at the folder net in the Project Explorer. There you will notice that the module HTTP Server is missing.

Include the HTTP Server module by creating a new Linked Folder located at STUDIO_SDK_LOC\platform\micrium_os\net\source\http\server

Open the new folder Properties and either include or exclude the folder from compilation as necessary from the section C/C++ Build.

Open the Project Properties and insert the location to the new header files ${StudioSdkPath}/app/micrium_os_example/net/http/server in the section C/C++ General -> Paths and Symbols

Locate and open the header file rtos_description.h and insert the following line to enable the new HTTP Server Module: #define  RTOS_MODULE_NET_HTTP_SERVER_AVAIL

Copy the configuration files from STUDIO_SDK_LOC\platform\micrium_os\cfg to your own workspace directory and make sure the compiler is aware of this include path.

Look at Table 1, locate the Example Basic Server That Uses the HTTP Static File System and explore the documentation.

Open the header file ex_description.h and insert the following line to enable the example: #define  EX_HTTP_SERVER_INIT_AVAIL

Create a new Folder named Examples and then create a Linked Folder in it that points to STUDIO_SDK_LOC\app\micrium_os_example\net\http\server

Open the Project Properties and insert the path ${StudioSdkPath}/app/micrium_os_example/net in the section C/C++ General -> Paths and Symbols

Open the file ex_main.c and insert the following line at the top: #include  "http/server/ex_http_server.h"

From the same file ex_main.c, locate the calls to the functions Ex_NetworkInit() and Ex_Net_CoreStartIF() and insert right after them, a call the following API to get the example started: Ex_HTTP_Server_InstanceCreateStaticFS();

 

 

The following blog explains a simple way of detecting task stack overflows while debugging your Micrium OS application.

Micrium OS Kernel Red Zone

The kernel's red zone is a feature that, when enabled through OS_CFG_TASK_STK_REDZONE_EN in os_cfg.h creates a monitored zone at the end of a task's stack. The length of the red zone is user-configurable via the #define OS_CFG_TASK_STK_REDZONE_DEPTH in os_cfg.h. By default, this is set to 8 stack elements (CPU_STK). 

When the red zone is enabled, every time a task is switched out, either at the task level or at the interrupt level, the kernel checks if the red zone has been hit. By default, a software exception is thrown with the use of the CPU_SW_EXCEPTION macro in the ARMv7m port. However, if you want more control over what your application should do in the event that the red zone is hit, you can turn on the application hooks by setting OS_CFG_APP_HOOKS_EN to DEF_ENABLED in os_cfg.h.

Using the Red Zone Application Hook

If you decided that you want your application to determine what to do in the event that a task hits the red zone instead of throwing a software exception, then you will have to define a hook function to do so.

A simple example:

static  void  RedzoneHitHook (OS_TCB  *p_tcb)
{
	BSP_LedSet(0);
	while(1);
}

 

With that, you can tell that if you see LED0 permanently on and with your code trapped at the while loop you have hit the red zone. You can then check p_tcp->NamePtr in your local variables panel and find what was the task that hit the limit.

Don't forget to assign the red zone hit hook pointer to your custom function. Using the example above:

OS_AppRedzoneHitHookPtr = RedzoneHitHook;

 

Make sure that this is added prior to calling OSStart() otherwise the pointer is never assigned to your application hook.

For more details about detecting stack overflows and the red zone, visit the following link: https://www.micrium.com/detecting-stack-overflows-part-2-of-2/

Over and over, customers tell us they want a wireless link to just work so they can move on and focus on the application they're designing. This week, we delivered on this challenge with the introduction of Wireless Xpress, which gives designers the freedom to go from out of box to prototype within a few hours – versus months – with no software development necessary.

Wireless Xpress provides a configuration-based development experience with everything developers need, including certified Bluetooth® 5 Low Energy (LE) and Wi-Fi® modules, integrated protocol stacks and easy-to-use tools supported by the Silicon Labs Gecko OS operating system.

The new solution simplifies wireless development and eliminates the daunting task of working in numerous and complicated wireless development interfaces. Today’s IoT development teams are often burdened with importing numerous stacks of software, dealing with hundreds of APIs and complex RF integration obstacles, along with writing hundreds of hours of code. Because of these complexities, wireless development is hard to come by, and IoT companies often need to outsource the development, an extremely costly and time-intensive process that slows down time to market. Wireless Xpress removes the need for wireless development since we’ve already done the work for you.

Then there’s cloud connectivity – an onerous challenge for design teams to build from the ground up.  Wireless Xpress provides instant cloud connectivity and has built-in firmware updates, along with the ability to retrieve updates and push them out to devices in the field. This functionality removes the need for our customers to pay for subscription-based services to ensure these updates are managed.

Wireless Xpress addresses all of these challenges head-on without a big stack. We take on as much firmware responsibility as possible, with all configuration occurring in the Gecko API.  Wireless Gecko is not codeable, but configurable, freeing designers from the headache of wireless design by getting it all in one box.

 

Putting Application First, Versus Network

Another challenge solved by the new solution, and especially beneficial for low-power applications, is MCU processing constraints. An MCU in a typical wireless design is handling all of the network processing demands versus application needs, creating a situation where customers are often paying more than they need for an MCU. Wireless Xpress offloads the embedded host processing from the MCU and handles processing demands inside the package, reducing the processing performance required and optimizing the chip-set. With Wireless Xpress, you can use a bare bone 8-bit MCU for applications that would have otherwise needed a 32-bit because of RAM, flash, etc. demands.

 

Support Down to the Silicon

With the Wi-Fi and Bluetooth modules, Silicon Labs is able to go all the way down to the silicon to find a problem. When you look at other pre-programmed modules on the market, what you find is module vendors are not SoC designers – the silicon in these products is from other companies. Therefore, in the support structure, problems tend to be punted to the underlying silicon vendor. This structure really goes against the ease of use experience. Wireless Xpress gives customers one point of contact for wireless design, making it much easier for support and troubleshooting. It’s our silicon – we control every part of the flow, giving us the advantage to optimize design better than anyone on the market.

Our Bluetooth and Wi-Fi modules are pre-programmed, pre-qualified and are pin for pin compatible with our portfolio of products. And they all run through the Gecko Xpress API, which we have already tested to ensure its reliability and flexibility. We’re taking care of the wireless interface on behalf of the customer and giving them back the 3-6 months it would take to build all of the connectivity from scratch.

So many of our customers seeking wireless connectivity are long-standing, established companies in markets that don’t have the in-house resources nor budget to invest in wireless connectivity talent – these companies’ main agenda is to make exceptional products for their markets. Wireless Xpress gives these companies the opportunity to obtain the wireless expertise they need in one package – giving time back to the developers to worry about their own customer needs – instead of complex wireless scenarios that demand too much time and money.

Wireless Xpress is the latest culmination of our strong customer relationships – we listen and design accordingly. Stay tuned as Silicon Labs continues to deliver the IoT solutions designers want to get innovative and high-performing products to the market as fast as possible.

Learn more at silabs.com silabs.com/products/wireless/xpress. 

 

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.