Kjetil, the plan is to have an updated example with v2.7 in the next 4 weeks.

Regards,

Juan.

Hi Kjetil, 

Perhaps it would be better to use an example for the WGM160P that we recently published in GitHub.

The example includes Micrium OS Kernel + lwIP and Wi-Fi which is more than what you need but, I think removing lwIP and Wi-Fi from the project would be a lot easier than porting a SLSTK3701A example to the WGM160P.

If you want to try that, follow this document, the part about Cloning the GitHub repo and importing it in Simplicity Studio in particular:

https://docs.silabs.com/wifi/wf200/content-source/getting-started/silabs/wgm160/getting-started

Regards,

Juan.

Hi Joshua, I tried your main.c and it worked fine; as the kernel is able to schedule your Test Task successfully.

I can verify this with our Probe tool and by defining RTOS_DEBUG_MODE to 1

With this tool, you can see the kernel run-time statistics including the context switch counter for each task.

If you are trying to verify if the task is running by setting a breakpoint inside your Test Task, then the problem is because the example has a high level of compiler optimization. If this is the case, then the solution is to temporarily set the compiler optimization to -Og (optimize for debugging) as follows:

    Project Properties -> Settings -> GNU ARM C Compiler -> Optimization

Regards,

Juan.

Hi Joshua, I tried your main.c and it worked fine; as the kernel is able to schedule your Test Task successfully.

I can verify this with our Probe tool and by defining RTOS_DEBUG_MODE to 1

With this tool, you can see the kernel run-time statistics including the context switch counter for each task.

If you are trying to verify if the task is running by setting a breakpoint inside your Test Task, then the problem is because the example has a high level of compiler optimization. If this is the case, then the solution is to temporarily set the compiler optimization to -Og (optimize for debugging) as follows:

    Project Properties -> Settings -> GNU ARM C Compiler -> Optimization

Regards,

Juan.

Hello Joshua,

Yes, Micrium OS changed between SDK v2.6 and SDK v2.7:

The Tick Task and Idle tasks are gone. Therefore, make sure you remove anything related to them including their config structures, stacks and TCBs. At the same time, the source file os_tick.c is gone and there is no need to call BSP_TickInit() anymore.

Because the Idle task is gone, then the Idle hooks (in case you have any) won't work anymore.

And finally, the sleeptimer change, which is I think the root cause of the problem you are seeing. 

In general, the sleeptimer change is basically the following:

1. Remove from your project the files:

    /platform/micrium_os/common/source/clk/clk.c
    /platform/micrium_os/common/source/clk/clk_cmd.c
    /platform/micrium_os/kernel/source/os_tick.c

2. Add the following files:

    /platform/emlib/src/em_rtcc.c
    /platform/common/src/sl_slist.c
    /platform/service/sleeptimer/src/sl_sleeptimer.c
    /platform/service/sleeptimer/src/sl_sleeptimer_hal_rtcc.c

3. Add the following include paths:

    /platform/service/sleeptimer/config
    /platform/service/sleeptimer/inc
    /platform/service/sleeptimer/src
    /platform/common/inc 

I think you need to make sure all the timing functions work before testing any of the Micrium OS run-time statistics (RTOS_DEBUG_MODE).

I ran a diff between soc-thermometer-rtos v2.6 and v2.7 and I see a couple of changes you may want to make sure you also have in place:

• New configuration file sl_sleeptimer_config.h
• Different reference clock for the clock branch cmuClock_SYSCLK in init_mcu.c (i.e. cmuSelect_HFRCODPLL instead of cmuSelect_HFXO)

I think the best strategy to do the migration is by comparing soc-thermometer-rtos v2.6 and v2.7 

Regards,

Juan.

Hello Joshua,

Yes, Micrium OS changed between SDK v2.6 and SDK v2.7:

The Tick Task and Idle tasks are gone. Therefore, make sure you remove anything related to them including their config structures, stacks and TCBs. At the same time, the source file os_tick.c is gone and there is no need to call BSP_TickInit() anymore.

Because the Idle task is gone, then the Idle hooks (in case you have any) won't work anymore.

And finally, the sleeptimer change, which is I think the root cause of the problem you are seeing. 

In general, the sleeptimer change is basically the following:

1. Remove from your project the files:

    /platform/micrium_os/common/source/clk/clk.c
    /platform/micrium_os/common/source/clk/clk_cmd.c
    /platform/micrium_os/kernel/source/os_tick.c

2. Add the following files:

    /platform/emlib/src/em_rtcc.c
    /platform/common/src/sl_slist.c
    /platform/service/sleeptimer/src/sl_sleeptimer.c
    /platform/service/sleeptimer/src/sl_sleeptimer_hal_rtcc.c

3. Add the following include paths:

    /platform/service/sleeptimer/config
    /platform/service/sleeptimer/inc
    /platform/service/sleeptimer/src
    /platform/common/inc 

I think you need to make sure all the timing functions work before testing any of the Micrium OS run-time statistics (RTOS_DEBUG_MODE).

I ran a diff between soc-thermometer-rtos v2.6 and v2.7 and I see a couple of changes you may want to make sure you also have in place:

• New configuration file sl_sleeptimer_config.h
• Different reference clock for the clock branch cmuClock_SYSCLK in init_mcu.c (i.e. cmuSelect_HFRCODPLL instead of cmuSelect_HFXO)

I think the best strategy to do the migration is by comparing soc-thermometer-rtos v2.6 and v2.7 

Regards,

Juan.

Hello Joshua,

Yes, Micrium OS changed between SDK v2.6 and SDK v2.7:

The Tick Task and Idle tasks are gone. Therefore, make sure you remove anything related to them including their config structures, stacks and TCBs. At the same time, the source file os_tick.c is gone and there is no need to call BSP_TickInit() anymore.

Because the Idle task is gone, then the Idle hooks (in case you have any) won't work anymore.

And finally, the sleeptimer change, which is I think the root cause of the problem you are seeing. 

In general, the sleeptimer change is basically the following:

1. Remove from your project the files:

    /platform/micrium_os/common/source/clk/clk.c
    /platform/micrium_os/common/source/clk/clk_cmd.c
    /platform/micrium_os/kernel/source/os_tick.c

2. Add the following files:

    /platform/emlib/src/em_rtcc.c
    /platform/common/src/sl_slist.c
    /platform/service/sleeptimer/src/sl_sleeptimer.c
    /platform/service/sleeptimer/src/sl_sleeptimer_hal_rtcc.c

3. Add the following include paths:

    /platform/service/sleeptimer/config
    /platform/service/sleeptimer/inc
    /platform/service/sleeptimer/src
    /platform/common/inc 

I think you need to make sure all the timing functions work before testing any of the Micrium OS run-time statistics (RTOS_DEBUG_MODE).

I ran a diff between soc-thermometer-rtos v2.6 and v2.7 and I see a couple of changes you may want to make sure you also have in place:

• New configuration file sl_sleeptimer_config.h
• Different reference clock for the clock branch cmuClock_SYSCLK in init_mcu.c (i.e. cmuSelect_HFRCODPLL instead of cmuSelect_HFXO)

I think the best strategy to do the migration is by comparing soc-thermometer-rtos v2.6 and v2.7 

Regards,

Juan.

Hello Joshua,

Yes, Micrium OS changed between SDK v2.6 and SDK v2.7:

The Tick Task and Idle tasks are gone. Therefore, make sure you remove anything related to them including their config structures, stacks and TCBs. At the same time, the source file os_tick.c is gone and there is no need to call BSP_TickInit() anymore.

Because the Idle task is gone, then the Idle hooks (in case you have any) won't work anymore.

And finally, the sleeptimer change, which is I think the root cause of the problem you are seeing. 

In general, the sleeptimer change is basically the following:

1. Remove from your project the files:

    /platform/micrium_os/common/source/clk/clk.c
    /platform/micrium_os/common/source/clk/clk_cmd.c
    /platform/micrium_os/kernel/source/os_tick.c

2. Add the following files:

    /platform/emlib/src/em_rtcc.c
    /platform/common/src/sl_slist.c
    /platform/service/sleeptimer/src/sl_sleeptimer.c
    /platform/service/sleeptimer/src/sl_sleeptimer_hal_rtcc.c

3. Add the following include paths:

    /platform/service/sleeptimer/config
    /platform/service/sleeptimer/inc
    /platform/service/sleeptimer/src
    /platform/common/inc 

I think you need to make sure all the timing functions work before testing any of the Micrium OS run-time statistics (RTOS_DEBUG_MODE).

I ran a diff between soc-thermometer-rtos v2.6 and v2.7 and I see a couple of changes you may want to make sure you also have in place:

• New configuration file sl_sleeptimer_config.h
• Different reference clock for the clock branch cmuClock_SYSCLK in init_mcu.c (i.e. cmuSelect_HFRCODPLL instead of cmuSelect_HFXO)

I think the best strategy to do the migration is by comparing soc-thermometer-rtos v2.6 and v2.7 

Regards,

Juan.

Hello Joshua, if an assert is hit with the error RTOS_ERR_SEG_OVF, this means the heap size is too small and needs to be increased.

Micrium OS uses this heap to allocate certain kernel objects.  And, it is not be confused with the C Heap that is configured from the project's compiler settings (i.e. __HEAP_SIZE=0xD00).

Unfortunately, our soc-thermometer-rtos example in the BLE SDK comes with the Micrium OS Heap size set to 0.

Try opening the configuration file common_cfg.h at the Project's root directory and set the heap size to 8K to get started until you know the exact size needed during runtime:

#define  LIB_MEM_CFG_HEAP_SIZE     8192uL

Regards,

Juan

Hello Joshua, if an assert is hit with the error RTOS_ERR_SEG_OVF, this means the heap size is too small and needs to be increased.

Micrium OS uses this heap to allocate certain kernel objects.  And, it is not be confused with the C Heap that is configured from the project's compiler settings (i.e. __HEAP_SIZE=0xD00).

Unfortunately, our soc-thermometer-rtos example in the BLE SDK comes with the Micrium OS Heap size set to 0.

Try opening the configuration file common_cfg.h at the Project's root directory and set the heap size to 8K to get started until you know the exact size needed during runtime:

#define  LIB_MEM_CFG_HEAP_SIZE     8192uL

Regards,

Juan