Member | Action | Date |
---|---|---|
![]() |
Replied
to
Micrium Exceptions on EFM32G11/WGM160P
Kjetil, the plan is to have an updated example with v2.7 in the next 4 weeks. Regards, Juan. |
Jan 23 2020, 4:09 PM |
![]() |
Replied
to
Micrium Exceptions on EFM32G11/WGM160P
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. |
Jan 22 2020, 9:49 PM |
![]() |
Replied
to
BGM210P Module Message Pool Issue
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. |
Jan 22 2020, 8:43 PM |
![]() |
Replied
to
Migrating Project From SLWSK to BGM210P Module?
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. |
Jan 22 2020, 8:42 PM |
![]() |
Updated
to
BGM210P Module Message Pool Issue
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 2. Add the following files: /platform/emlib/src/em_rtcc.c 3. Add the following include paths: /platform/service/sleeptimer/config 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:
I think the best strategy to do the migration is by comparing soc-thermometer-rtos v2.6 and v2.7 Regards, Juan. |
Jan 21 2020, 8:55 PM |
![]() |
Updated
to
Migrating Project From SLWSK to BGM210P Module?
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 2. Add the following files: /platform/emlib/src/em_rtcc.c 3. Add the following include paths: /platform/service/sleeptimer/config 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:
I think the best strategy to do the migration is by comparing soc-thermometer-rtos v2.6 and v2.7 Regards, Juan. |
Jan 21 2020, 8:55 PM |
![]() |
Replied
to
Migrating Project From SLWSK to BGM210P Module?
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 2. Add the following files: /platform/emlib/src/em_rtcc.c 3. Add the following include paths: /platform/service/sleeptimer/config 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:
I think the best strategy to do the migration is by comparing soc-thermometer-rtos v2.6 and v2.7 Regards, Juan. |
Jan 21 2020, 8:53 PM |
![]() |
Replied
to
BGM210P Module Message Pool Issue
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 2. Add the following files: /platform/emlib/src/em_rtcc.c 3. Add the following include paths: /platform/service/sleeptimer/config 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:
I think the best strategy to do the migration is by comparing soc-thermometer-rtos v2.6 and v2.7 Regards, Juan. |
Jan 21 2020, 8:53 PM |
![]() |
Updated
to
BGM210P Module Message Pool Issue
Hello Joshua, if an assert is hit with the error 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 |
Jan 20 2020, 10:16 PM |
![]() |
Replied
to
BGM210P Module Message Pool Issue
Hello Joshua, if an assert is hit with the error 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 |
Jan 20 2020, 10:15 PM |