embOS with SiLabs BLE library

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • embOS with SiLabs BLE library

      I'm working on a small private project where I want to use BLE to transfer data between my embedded system and a smartphone app. Below are some basic information before I start explaining my problem.

      1. Which embOS do you use?
      embOS_CortexM_GCC V506 with SES for ARM V4.42
      2. Which CPU and eval board do you use?
      EFR32MG12P433F1024GL125 CPU with EFR32MG12 starter kit
      3. Which start project do you use?
      Hello World project from EFR32MG12P sample projects

      Problem:
      I started by testing the eval kit with SiLabs Simplicity studio and the different example projects. First a singleloop project, then a pre-compiled project with SiLabs Micrium OS.
      As I got an understanding of how it works, I tried to implement the singleloop version with SES and it worked almost directly. As soon as I got it running, I tried to modify the singleloop project to use embOS with all possibilities of using an RTOS.
      The example project from Silabs (with Micrium OS) has several libraries which handles the BLE part and a wrapper (rtos_bluetooth.h, rtos_bluetooth.c) for the RTOS behaviour around the BLE libraries. As I understood, I just need to implement the
      same wrapper for embOS and it should work. I started with creating a basic project which initializes the OS and the required hardware (I took some ideas from embOS sample projects for another SiLabs eval board) and got basic tasks running (measuring the
      battery voltage every second and print it with RTT to RTT-Viewer). As I got the embOS running, I started with the implementation of the rtos_bluetooth wrapper. I copied the same structure that Micrium OS uses (the same tasks for BLE linklayer and BLE stack).
      The configuration structure for SiLabs BLE library contains some flags (if using an RTOS or not), basic bluetooth settings (max_connections, BLE heap, BLE heap size, linklayer priorities, and so on). The config strucutre can be found in gecko_configuration.h
      In addition when using an RTOS, the configuration structure also requires callback methods which are called from Interrupt context. This works at the beginning where I can initialize the bluetooth stack, setup the advertising parameters. As soon as I start advertising
      my program runs into OS_ERROR with OS_ERR_CPU_STATE_ISR_ILLEGAL. As far as I understand, this means that I cannot call the OS_EVENT_SetMask function because my program is in an ISR with higher priority. I have no clue how I can resolve this issue.
      I added my rtos_bluetooth wrapper files. The problem I'm facing happens after some time on Line 106 inside bluetoothLinkLayerCallback where I want to set the bitmask for my OS_EVENT.
      Any help is appreciated.

      I found in this link that I can use any RTOS I want if I modify the wrapper to use the new RTOS instead of Micrium:
      silabs.com/community/wireless/…multiprotocol_withou-j6io
      Files
      • embOSwithBLE.7z

        (4.21 kB, downloaded 70 times, last: )
    • As far as I understand, this means that I cannot call the OS_EVENT_SetMask function because my program is in an ISR with higher priority. I have no clue how I can resolve this issue.
      That's correct. embOS API must be called only from embOS interrupts with an according interrupt priority. That means you have to change the interrupt priority to a valid value.
      Please have a look here and in the embOS manuals: wiki.segger.com/Interrupt_prioritization


      Best regards,
      Til
    • I guess the interrupt is initialized in the BLE library and you don't have the source code, correct?
      Anyway you can change the interrupt priority at any time later before your application starts.
      You just need to know which interrupt is used (I think it's the RTCC interrupt) and change the according interrupt priority.
      But I cannot know whether the interrupt priority has an influence on the BLE stack.

      Best regards,
      Til
    • Hello Til

      I'm not 100% sure, but my guess goes to the same direction that all used interrupts are initialized inside the BLE library from SiLabs.

      I will contact SiLabs directly in order to get some information what interrupts they are using and if any changes on the priority has influence on the stability of the BLE feature.
    • Hello Til

      I was in contact with the support team from SiLabs and got the following remarks:
      Regarding the possibility to change some of their ISR priorities:

      This is correct, BLE is time sensitive and modifying the priorities of the ISR might cause instability in connections, advertisements, etc. I would not recommend to change this priorities.
      This is the way Micrium OS and OSFlagPost are designed. This function was made so it may be called from a kernel aware ISR.
      Check if embOS has an API specially made for this (e.g. FreeRTOS has the xEventGroupSetBitsFromISR() API call to do this.)

      So, I know from my experience that it is not an option to change stuff inside the BLE library as it is really time sensitive. This results in the last remaining option where I need to find a solution with embOS. But I've never found some information about functions that can be called from a kernel aware ISR...
      Do you have another idea how to resolve this? If not, I have to get back to Micrium OS and do the project in this environment...
    • westloser86 wrote:

      This is correct, BLE is time sensitive and modifying the priorities of the ISR might cause instability in connections, advertisements, etc. I would not recommend to change this priorities.
      With Cortex-M the absolute interrupt priority value is not crucial but the comparison of two priorities. For example it makes no difference whether the interrupt priority is 0x00 or 0x80 if this is the only interrupt.

      Let's say the BLE stack initializes a BLE interrupt at priority 0x00 and you have a system tick interrupt at priority 0x10. Since 0x00 is the highest interrupt priority it will always be served first. if you now would use embOS interrupt priorities like 0x80 for the BLE interrupt and 0x90 for the system tick it would work the same but these values would be valid embOS interrupt priorities. Please understand these values just as an abstract example since the actual possible Cortex-M interrupt priorities depend on the implemented priority bits. Please have a look here for more details: wiki.segger.com/Interrupt_prioritization .

      Another option would be to change the priority limit between embOS interrupts and zero latency interrupts which is possible with the embOS Cortex-M source code.
      Which interrupts at which interrupt priority are used by the BLE stack?