Profile Data
| Member | Action | Date |
|---|---|---|
|
Janos Magasrevy
|
Updated Adding Micrium OS on a Flex Gecko on Blog
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 StartedI 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:
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 ExampleAs 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 WorkspaceNow 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:
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:
Configuring Micrium OSNow 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.
Modifying main.cWe'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:
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:
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:
Let's now modify main() to initialize the CPU, the kernel create the Start Task, and start the OS. Here's how main() should end up looking:
Finally, since Micrium OS makes use of an assembly-optimized memory copy function, you must enable it in common_cfg.h
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. |
53 days ago |
|
Janos Magasrevy
|
Updated to Need More Sample Examples Related to Micrium OS 2 Show more |
55 days ago |
|
Janos Magasrevy
|
Replied to Need More Sample Examples Related to Micrium OS 2 Show more |
58 days ago |
|
Janos Magasrevy
|
Replied to Flex Gecko with Micrium os Show more |
Jan 18 2019, 10:46 AM |
|
Janos Magasrevy
|
Updated Detecting Task Stack Overflows Through the Kernel's Red Zone Feature on Blog
The following blog explains a simple way of detecting task stack overflows while debugging your Micrium OS application. Micrium OS Kernel Red ZoneThe 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 HookIf 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:
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:
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/ |
Nov 16 2018, 1:33 PM |
|
Janos Magasrevy
|
Updated Detecting Task Stack Overflows Through the Kernel's Red Zone Feature on Blog
The following blog explains a simple way of detecting task stack overflows while debugging your Micrium OS application. Micrium OS Kernel Red ZoneThe 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 HookIf 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:
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:
Make sure that this is added prior to calling OSStart() otherwise the pointer is never assigned to your application hook. |
Nov 15 2018, 4:10 PM |
|
Janos Magasrevy
|
Posted Detecting Task Stack Overflows Through the Kernel's Red Zone Feature on Blog
The following blog explains a simple way of detecting task stack overflows while debugging your Micrium OS application. Micrium OS Kernel Red ZoneThe 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 HookIf 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:
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:
Make sure that this is added prior to calling OSStart() otherwise the pointer is never assigned to your application hook. |
Nov 15 2018, 4:07 PM |
|
Janos Magasrevy
|
Updated Micrium OS File System RAM Disk on EFM32GG11 on Blog
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 ProjectSince 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...
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 FilesWe 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:
Editing the Example FilesAt 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:
Paste the two files in your workspace folder, at the same level of ex_fs.c, etc. In my case, this would be:
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:
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.
Running the ExampleYou 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:
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. |
Sep 21 2018, 11:20 AM |
|
Janos Magasrevy
|
Updated Micrium OS File System RAM Disk on EFM32GG11 on Blog
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 ProjectSince 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...
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 FilesWe 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:
Editing the Example FilesAt 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:
Paste the two files in your workspace folder, at the same level of ex_fs.c, etc. In my case, this would be:
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:
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.
Running the ExampleYou 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:
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. |
Sep 21 2018, 11:19 AM |
|
Janos Magasrevy
|
Updated Micrium OS File System RAM Disk on EFM32GG11 on Blog
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 ProjectSince 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...
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 FilesWe 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:
Editing the Example FilesAt 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:
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
#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.
/* ----------------- FORMAT RAM DISK ------------------ */
#if (defined(RTOS_MODULE_FS_STORAGE_RAM_DISK_AVAIL))
{
FS_BLK_DEV_HANDLE blk_dev_handle;
/* Format RAM Disk as a FAT volume. */
blk_dev_handle = FSBlkDev_Open(FSMedia_Get("ram0"), &err);
APP_RTOS_ASSERT_CRITICAL(err.Code == RTOS_ERR_NONE, ;);
/* Assign cache to this device. */
FSCache_Assign(blk_dev_handle,
Ex_FS_DataPtr->CachePtr, /* Pointer to cache instance previously created. */
&err);
APP_RTOS_ASSERT_CRITICAL(err.Code == RTOS_ERR_NONE, ;);
FS_FAT_Fmt(blk_dev_handle,
FS_PARTITION_NBR_VOID, /* Only 1 partition. */
DEF_NULL, /* Format with default values. */
&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 ExampleYou 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. |
Sep 21 2018, 11:17 AM |
Level 4
Level 3