Posts by SEGGER - Til

    Hello Vadym,

    Sounds like you did not add the embOS library to your project.

    Yes, we have support for STMCubeMX. Please have a look here:
    https://wiki.segger.com/Using_embOS_with_STM32CubeMX

    No, we don't have a STM32WB55 BSP with embOS Cortex-M GCC so far (which is the correct embOS port for STM32CubeIDE):
    https://www.segger.com/products/rtos/…s-cortex-m-gcc/

    But that can easily be created for your evaluation.
    Please feel free to contact us directly via our ticket system or support email address:
    https://www.segger.com/doc/UM01001_embOS.html#Support

    Best regards,
    Til

    Hello Jim,

    yes, you can use embOS spinlocks to synchronize data messaging between two or more cores.
    If you have an embOS instances running on each core you usually have a shared memory in which you can pass data from one core to the other.
    This shared memory must be secured with a spinlock. That's a generic way which works with every core.

    But most devices have device specific mechanism to communicate between the cores like triggering an interrupt on the other core.
    It depends on you application and device what works best for you.
    We will create a simple spinlock sample project for the STM32H745.

    Btw. We are currently working on embOS SMP implementation. With it you have one embOS instance running on all cores and you can use all existing embOS API like mailbox and queues to share data between the cores. If you don't use an affinity mask for a specific task you even don't have to care about on which core the task is currently running and it simply works.

    Best regards,
    Til

    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: https://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?

    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

    Quote

    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: https://wiki.segger.com/Interrupt_prioritization


    Best regards,
    Til

    Dear Giacomo,

    Since in the method interrupt_handler() I make some calls to OS functions (like OS_PutMail used for mailboxes) If I'm not mistaken I have to tell the OS that I'm within an interrupt, with the methods OS_EnterInterrupt() and OS_LeaveInterrupt().

    Yes, that's correct.

    Which error code do you get? Most likely you are using an invalid interrupt priority.
    The iMXRT1062 has four interrupt priority bits implemented, thus NVIC_SetPriority() expects values from 0 to 15 and 0 is the highest priority.

    NVIC_SetPriority(CAN2_IRQn, 5u);

    This is an invalid interrupt priority for embOS interrupts. Please try e.g. NVIC_SetPriority(CAN2_IRQn, 10u) instead.

    Please have a look here for more details: https://wiki.segger.com/Interrupt_prioritization

    Does that solve your issue? If not please let me know.

    Best regards,
    Til

    Hello Alexander,

    IAR changes the runtime model from time to time.
    This messages says that the embOS libraries were built with an older runtime model.
    Unfortunately there is no easy fix.
    The embOS libraries needs to be rebuilt with your IAR version.
    And we must check whether there is something we need to modify in our code.

    Please contact us directly per email or our ticket system and we'll help you with the evaluation.
    You can also give me a call to discuss further details.

    Best regards,
    Til

    Hallo Philipp,

    üblicherweise passiert das wenn das Interrupt Pending Flag nicht gelöscht wurde.
    Du müsstest mal schauen, ob es das bei deinem Device gibt und es dann in der Interrupt Routine als erstes löschen.
    Ansonsten sieht der Interrupt Controller das ein Pending Flag gesetzt ist und führt die ISR sofort wieder aus.
    Das sollte aber ohne embOS genauso passieren.
    Löst das dein Problem?

    Btw. Ein OS_INT_Call() brauchst du nicht. Das wird nur bei manchen speziellen CPUs gebraucht.
    Eine embOS Interrupt Routine beim Cortex M sieht so aus:

    C
    void USART2_IRQHandler(void) {
      OS_INT_Enter();
      DoSomething();
      OS_INT_Leave();
    }


    Gruß,
    Til

    Korrekt, der embOS Timer wird in der OS_InitHW() in der RTOSInit.c initialisiert.
    Dazu passend müssen dann einige Sachen in der RTOSInit.c angepasst werden damit alle embOS Timing Funktionen über den neuen Timer informiert sind.
    Das ist aber fast selbsterklärend (z.B. OS_TIMER_FREQ auf die richtige Frequenz des genutzten Timers setzen).

    Ich würde aber empfehlen den anderen Weg zu versuchen. Das ist eigentlich einfacher.
    Im Zweifelsfall kannst du uns auch dein Projekt schicken und wir schauen mal, ob wir dir weiterhelfen können.

    Am besten dann über unser Ticket System oder über die Support Emailadresse (findest du im embOS Manual im Kapitel Support).

    Viele Grüße,
    Til

    Hallo Philipp,

    wenn ich das richtig im Kopf habe wird der SysTick in der STM32F10x_StdPeriph_Driver nur für Timeouts benutzt.
    D.h. dort wird wahrscheinlich nur irgendein Zähler inkrementiert.
    Das einfachste wäre also den SysTick in der STM32F10x_StdPeriph_Driver nicht zu initialisieren und das Inkrementieren in unserem SysTick Interrupt Handler auszuführen.

    Alternativ könnte man natürlich auch für das embOS einfach einen anderen Hardware Timer benutzen.
    embOS ist nicht auf den SysTick angewiesen. Jeder andere Hardware Timer funktioniert auch.


    Gibt es irgendeine Möglichkeit meinen Code aus dem vorherigen Projekt zu verwenden oder muss ich alle defines und Schnittstellen Implementierungen neu schreiben?

    Du musst auf keinen Fall irgend etwas neu implementieren. Die Benutzung von embOS mit solchen Libraries ist quasi Standard und wird von vielen Kunden benutzt.


    Viele Grüße,
    Til

    Hello,

    thanks for your inquiry.

    1. Where can I found information about the OS_Init() function?

    Please have a look in the embOS manual which comes with your embOS shipment.
    It is also available online at: https://www.segger.com/downloads/embos/UM01001


    2. Can I take the embOS example as init structure only use for the RTOS, so Is it right to use all the clock setting and power by the serial example as is or I need to understand what HW setting the embOS example all ready done?

    OS_Init() does initialize core specific stuff only . With Cortex-M that's the PendSV interrupt priority and FPU settings only.
    Further initialization is done in OS_InitHW() which is shipped as source code.
    The embOS clock initialization is done in the device specific CMSIS files.
    There might be some settings which should not be initialized twice.

    Please let me know if I can be of any further help.

    Best regards,
    Til

    Dear Audrey,

    in my understanding you are using the embOS RX CCRX sources with the IAR EWRX compiler and implement the necessary changes by yourself instead of licensing embOS RX IAR, right?
    Most likely there is no bug in embOS but in your implementation.
    What you are currently using is no embOS provided and tested by SEGGER!
    embOS RX IAR is used in a lot of products without any issues.

    > This bug appears when two interrupts (nested or with different priorities) run at same time (one interrupts the other) and both have > to call "_OS_SwitchFromInt".
    This will not happen since only the first interrupt calls OS_SwitchFromInt().

    Please understand we can't give support for your customized embOS and your license agreement does not cover the usage of the IAR compiler. The simplest solution is to license embOS RX IAR. If you want to give it a try you could download the embOS RX IAR trial version from segger.com.

    Best regards,
    Til

    Hi Ran,

    OS_TASK_EnterRegion()/OS_TASK_LeaveRegion() disables preemptive task switches.
    Whether this has any effect on the BLE stack depends on your application and the BLE stack itself with which I am not that familiar with.

    Is the BLE communication handled in a task or in interrupts?

    Best regards,
    Til