Hi Silvio,
We're not aware of any issues regarding Taskevents in embOS 5.18.0.3.
OS_TASKEVENT_Set() should immediately switch to the signaled task if that has the highest priority in the application, is not suspended and no critical region was established.
Since your embOS license should be still in support, please create a Support Ticket and I'm pretty sure we'll be able to solve that issue quickly.
Best regards,
Martin
Hello Ali,
Okay, so you're including the STM32Cube HAL directly from within Keil MDK.
This combination is not something I have used before and since neither product is supported by SEGGER, I'm afraid I can be of limited help here only.
However, I'd assume that combination to work just as well after applying the modifications I had suggested above:
As mentioned before, for a straight-forward evaluation of embOS, you might also be interested in using embOS for Cortex-M and Keil MDK or, even better, embOS for Cortex-M and Embedded Studio instead.
Best regards,
Martin
Hello Ali,
I'm not quite sure about your set-up in this particular case.
SEGGER.I-CUBE-embOS_conf.h should be generated by STM32CubeMX when creating a project that was configured for embOS.
However, it seems the *.ioc file included with your project files was not configured for embOS usage.
If so, you may simply cut the inclusion of SEGGER.I-CUBE-embOS_conf.h from RTOSInit.c.
Please be aware, however, that you will also need to disable the generation of the SysTick_Handler() and PendSV_Handler() in CubeMX and possibly apply further modifications as well.
Please refer to our Wiki for further information on how to integrate embOS into a CubeMX-generated project that was not configured for embOS usage.
By the way:
embOS for Cortex-M and Keil MDK includes a sample project for an STM32F0 as well (for the STM32F051R8-SK board), hence you might want to consider using that for your evaluation.
embOS for Cortex-M and Embedded Studio includes sample project for various STM32F0 devices and may therefore be an even better choice for evaluating embOS.
Best regards,
Martin
Hi again,
Also Please note that my keil version is 5.38 and I'm using arm compiler version 6.19 and I have also tried to compile your STM32F103_STM32_SK example, and I would get the compilation error like this
(...)
Setup/Retarget.c(345): error: conflicting types for '_sys_tmpnam'
int _sys_tmpnam(char * pBuffer, int FileNum, unsigned MaxLen) {
It seems Keil MDK has changed the signature of the _sys_tmpnam() function from
int _sys_tmpnam() in uVision v5.36 and earlier to
void _sys_tmpnam() in uVision v5.38.
Thanks for making us aware of this!
I have modified Retarget.c accordingly and attached it to this post.
Using that modified file, I was able to build our reference project for the STM3210-Eval board in uVison v5.38.
We will also include this modification in upcoming releases of embOS for Cortex-M and Keil MDK.
Regarding the initial problem:
.\Objects\marlin.axf: Error: L6915E: Library reports error: Conflicting stack/heap set up methods in use. __user_setup_stackheap, __user_initial_stackheap cannot be used with __initial_sp, __heap_base and __heap_limit
According to the documentation, this means the project is now using two different methods of heap/stack initialization when it must use one of those only:
- Error: L6915E: Library reports error:Conflicting stack/heap set up methods in use. __user_setup_stackheap, __user_initial_stackheap cannot be used with __initial_sp, __heap_base and __heap_limit
You have most likely used __initial_sp, __heap_base, or __heap_limit to set up the stack and heap, but other independent stack and heap setup methods, __user_initial_stackheap or __user_setup_stackheap, are also in use. Use only one of the following stack and heap setup methods:
- __initial_sp, __heap_base, __heap_limit.
- __user_setup_stackheap.
- __user_initial_stackheap. The legacy function. Arm recommends not using __user_initial_stackheap(), if possible.
Since embOS expects the symbols __initial_sp, __heap_base, __heap_limit in the start-up file, that method must be used with embOS.
Consequently, __user_setup_stackheap may not be used and must be removed from the start-up file.
I have modified startup_stm32f10x_hd.s accordingly and attached that as well.
Using that modified file, I was able to build your sample project in uVison v5.38.
Do the modified files solve the observed issues for you as well?
Please lt me know if I can be of any further help.
Best regards,
Martin
Dear Ali Asadzadeh,
Thanks for your inquiry.
I assume you are following our Wiki page on creating CMSIS-based projects with embOS?
In that case, adding the EXPORT directives you have mentioned to the start-up file is the correct solution to the observed problem, as mentioned in the Wiki.
Please note that modification to OS_InitSysStackInfo.c is not a proper solution, since embOS will use the variables that are initialized therein for debug purposes.
By commenting out their initialization, embOS will effectively assume the System Stack to be located a address 0x00, which will result in memory faults when embOS writes an initial pattern byte to that address.
embOS does require the symbols __initial_sp and Stack_Mem to be accessible from C-Code, hence adding them to the start-up file is required when these symbols are not exported by default.
.\Objects\marlin.axf: error: L6002U: Could not open file .\objects\startup_stm32f10x_md.o: No such file or directory
This indicates that startup_stm32f10x_md.s was not correctly build after adding the EXPORT directives.
Can you please confirm it builds properly with your project?
Also, embOS for Cortex-M and Keil MDK comes with various sample projects for different evaluation boards, and these projects' start-up files of course include the required export directives already.
You could use one of those as a template, e.g. startup_stm32f10x_hd.s contained in our shipped start project for the STM3210E-Eval board (the projects are available for evaluation and may be retrieved from our website).
Does that solve the observed issue?
Please let me know if I can be of any further help.
Best regards,
Martin
Hi Dimitri,
Can you give more information on what specific embOS port and version you are working with?
Hi!
I think this is not a "normal" value of this variable and that it may somehow have gotten corrupted.
OS_Global.InInt (or, in previous versions, OS_InInt) is increased once for every call to OS_INT_Enter[Nestable](), but application interrupts typically will not nest each other more than 200 times. I'd therefore agree that this is likely due to a corruption of that variable.
Do you have tips on how I could debug this issue ?
Depending on the used architecture, IDE and/or debug probe you might be able to configure data watch points that trigger when the upper bits of OS_InInt are written to. Since this will not happen in typical applications where interrupts do not nest each other that often, this should then give you an idea on what part of the application is corrupting the variable.
Please feel free to contact us via Email or our support ticket system as well in case you're entitled to regular embOS support (i.e. you have a valid "support & update agreement"). This will also allow to share snippets of embOS source code - please refrain from posting them here. Thank you for your understanding!
Best regards,
Martin
Hello,
In Generic CMSIS project in ReadMe.txt Supported hardware is: "The sample project for CMSIS should run on any Cortex M3 core."
Can the project be used with M4? What is limitation or required changes to use it with Cortex M4?
Are you, by any chance, referring to the Generic CMSIS project contained in embOS for Cortex-M and IAR?
In that case, the project may also be used with Cortex-M4, of course.
From an RTOS perspective, M3 and M4 don't differ much except for the additional FPU with Cortex-M4.
Hence, as long as the FPU is kept disabled, the project may be used with Cortex-M4 devices without further modifications.
If the M4's FPU shall be used, however, the embOS libraries need to be exchanged for appropriate libraries that include FPU support (refer to "Naming conventions for prebuilt libraries" inside the manual UM010014)
Furthermore, the device support files contained in the project would need to be exchanged as well in order to utilize an FPU. Since you're probably intending to use the project in real hardware, it should be sufficient to simply replace the shipped generic files with the appropriate device support files provided by your device vendor (the latter also is suggested if using the project on a M3 hardware).
Please let me know if I can be of any further help.
Best regards,
Martin
Hello,
I have been able to use SystemView in IAR's debug mode but when in release mode it does not work.
Is there a way to get this to work in release mode?
Thanks
I assume you're still working with embOS for Cortex-M and IAR, am I correct?
In that case, please be aware that embOS itself does not generate SystemView events in release builds, but in profiling builds only (i.e. "debug & profiling", "debug & trace", or "stack check & profiling").
Furthermore, our BSPs are configured to start SystemView in profiling builds only as well. Hence, even if your application does generate some SystemView events on its own, the initial SysView configuration may still be missing.
To resolve the latter, you'd then need to modify your RTOSInit.c, which contains the following code snippets:
#if (OS_SUPPORT_PROFILE != 0)
if (SEGGER_SYSVIEW_DWT_IS_ENABLED() == 0u) {
SEGGER_SYSVIEW_TickCnt++;
}
#endif#if (OS_SUPPORT_PROFILE != 0)
SEGGER_SYSVIEW_Conf();
#endifBy removing the dependency on OS_SUPPORT_PROFILE from these snippets, SystemView gets configured in release builds as well and should then be usable by your application.
Does this solve the observed issue?
Best regards,
Martin
Hi vadymsodolevsky,
What is the easiest way to use embOS with NRF soft device? I see 2 options:
1. Use as the base the embOS IAR project (with the 3 changes), remapping the application, add BLE component to work with SoftDevice?
2. Use the NRF SDK, add embOS as SW library and adopt the project to work with it in the same way as FreeRTOS works? (currently chosen)
Both options would work, of course. However, option 2) probably is more easy to perform, since integrating embOS into an existing project is quite straightforward and requires few modifications only (including the libs and RTOSInit.c, configuring appropiate include paths and ultimately creating a task that executes the superloop of the existing bare-metal application). Integrating the softdevice into an existing embOS project, on the other hand, will likely require some more modifications (e.g. adding the additional hex file, appropriately configuring the project and linker files, writing the application from scratch, etc.).
As a reference on option 2), I will provide you with the aforementioned project that we had created based on SDK version 12.2.0. Please check your inbox for the download link in a few minutes.
Best regards,
Martin
Dear vadymsodolevsky,
Thank you for your inquiry.
Quote from vadymsodolevsky1. Does somebody tested the embOS with Ble(SOFT DEVICE) and with System Core Clock?
2. Do you have example or somebody else implemented for "app_timer" for Nordic SDK (API between BLE and OS timers)?
3. Do you have some tips for me about the porting to NRF? May be I didn't found in forum the porting sequence from somebody else?
After receiving some customer requests on this topic, we've performed several tests some time ago to see whether any modifications need to be done to embOS or to our BSPs in order to use those with Nordic's softdevices.
Eventually, we've found embOS to be fully compatible, while two minor modifications were required to our BSPs only (+ a third one when working with very old versions of our BSPs). We've documented those changes to the BSPs at:
https://wiki.segger.com/Using_embOS_with_Nordic_BLE
Please be aware that our tests had been done using SDK version 12.2.0. However, I'm not aware of any changes to the SDK that would have broken compatibility between embOS and Nordic's softdevices.
Specifically, working with SystemCoreClock did work flawlessly during our tests. Are you experiencing any issue when working with it? If so, can you describe that in more detail?
Best regards,
Martin
Hello Enes,
Thanks for your inquiry.
embOS spinlocks are typically implemented in assembler using atomic instructions specific to the architecture in use.
For architectures that do not support appropriate atomic instructions, however, we also offer another implementation that's completely written in "C".
For the latter, we've implemented the well-known "Lamport's bakery algorithm" (refer to http://research.microsoft.com/en-us/um/peopl…pubs/bakery.pdf for more information).
Of course, both implementations include appropriate memory and optimization barriers to account for possible memory reordering with modern microcontrollers.
Please understand, however, that this is rather a theoretical question than a question on embOS and its usage, and thus unfortunately is not covered by our support.
For further reading, e.g. on barriers on ARM Cortex-M, I'd recommend https://static.docs.arm.com/genc007826/a/B…ookbook_A08.pdf
Best regards,
Martin
Hi Bhu,
Thank you for your inquiry.
Please be aware, however, that interrupt simulation with IAR's Embedded Workbench is not covered by the embOS support, but would need to be discussed with IAR instead.
Hence I'm afraid I can be of limited help on this only. Still, please consider the following:
embOS 4.24 for RX and IAR (as well as later versions) includes a dedicated IAR simulator project at {ROOT_DIR}\Start\BoardSupport\IAR_Simulator\.
That project comes with specific macro file to simulate the SysTick interrupt (CSpy_Sim.mac inside the Setup\ folder) and is working flawlessly for us.
Hence, may I ask whether you had use that project for your simulation as well? Or did you create a new project from scratch?
In the latter case, we'd suggest using the macro file that was provided with our project as a template for yours.
Please let me know if I can be of any further help.
Best regards,
Martin
Hi Kees,
As Nino explained, embOS v3.62 would need to be instrumented for using SystemView on it, which may only be done when having access to the source code.
However, if you're interested in CPU load exclusively, there might be an alternative that was available in v3.62 already: embOSView. embOSView displays the CPU load per task and thus could be used as an indicator on whether you're exceeding the devices capacities. For more information on embOSView, please refer to the generic embOS manual UM01001: with v3.62, all relevant information on this is contained in chapter 20, "embOSView: Profiling and analyzing".
Best regards,
Martin
Hi Shinkyu,
Hi Martin,
Thank you for your detailed explanation.
How can I contact you if there is anything more to discuss about this?Best Regards,
Shinkyu Park
You're welcome!
Our official support email address is support_embos@segger.com[/email].
Alternatively, you may also use our ticket system at segger.com/ticket.
Best regards,
Martin
Hi Shinkyu,
Thanks for your inquiry!
When I change the period of Timer as 500us, tick interrupt is generated in every 500us.But timer related APIs are not work properly.
When I call OS_Delay(1000), it expires after 500ms.
This actually is expected behavior. OS_Delay() [or OS_TASK_Delay() as it's called in recent versions] doesn't take milliseconds as a parameter, but system ticks. Therefore, by doubling the system tick interrupt's frequency, all delays will expire twice as fast.
Quote from shinkyu.parkIs there anything I need to do?
I'm using embOS 4.22.
If you want timeouts to be based on milliseconds even when the system tick interrupt is not, there's three different options in general:
Does this answer your question? Please let me know if I can be of any further help.
Best regards,
Martin
Glad you're up and running again!
We'll consider this thread closed now.
Best regards,
Martin
Hello,
While we're not aware of any issues regarding OS_TICK_Handle(), we'd of course like to help you in finding the cause for the observed behavior.
Generally speaking, OS_ERR_ILLEGAL_OUT_ISR is indicated whenever embOS assumes that an API function that may only be called from an ISR was called from a context that is not an ISR.
This is done by checking the variable OS_Global.InInt, which should have been incremented before by calling either OS_EnterNestableInterrupt() or OS_EnterInterrupt().
This, in return, would indicate that your code does not actually call either of these functions, though the code snippet provided above does clearly show a call to OS_EnterNestableInterrupt(). Alternatively, OS_Global.InInt may also have been corrupted by the application, which could then result in the exact same behavior. Hence, could you please check if the code gets in fact executed and OS_Global.InInt gets incremented from 0 to 1?
Calling OS_CallNestableISR() - while it seems to solve the problem - unfortunately is not a proper solution. That function is mandatory to use for certain architectures, but Cortex-M is none of these architectures. Since the function merely calls OS_EnterNestableInterrupt() and then executes the given ISR routine, the sudden change in behavior would once more indicate that OS_EnterNestableInterrupt() was not called explicitly.
By the way: Since you're working with embOS 4.26, you may also want to have a look at https://www.segger.com/products/rtos/…s-cortex-m-gcc/ , for more recent versions of embOS for Cortex-M and GCC do provide several start projects for STM32L4 devices that could serve as a starting point for your own project. Also, please have a look into the release notes on that page, too: Recent versions contain various new features and improvements that could be of interest to you as well, hence you might want to consider updating embOS to one of these versions.
Please let me know if I can be of any further help.
Best regards,
Martin
Hi Bar,
Quote from BarDo you see why this could happen?
OS_ERR_INV_TASK indicates that the task was not created before, or else that the task's control block was overwritten by the application after it was created.
Hence, could you please double-check that the task was actually created before the event gets signaled? Also, if it was created before, could you check wether the member "Id" of the respective task's control block holds the value "0x0Fu" at all times after creating that task?
Quote from BarIs there a missing stack also for the event structure?
No. OS primitives such as events do not require a stack of their own.
Quote from BarNow I have time for this and I check your first suggestion with the event,
Is this really necessary?
While signalling a task event from a software timer can make sense in specific situations, we'd typcially advise to execute the desired functionality directly inside the software timer's callback function if that's possible. Otherwise, a task can be made periodic by calling OS_TASK_DelayUntil() - then, no software timer is required at all.
As mentioned previously, if you were to give some more details on the job you're trying to perform periodically, we should be able to suggest the most appropriate approach to doing that with embOS.
Best regards,
Martin
PS, after having just seen your additional post:
Quote from BarNow it work
I'm glad to hear that! Still, you might want to re-consider whether signlling a task from the software timer really is necessary, or if OS_TASK_DelayUntil() would do the trick already.
Quote from BarIf we talk, what about the error on the plug in?
We'll notify you once an updated version of the plug-in becomes available.
Please let me know if I can be of any further help.
Best regards,
Martin
Hello bar,
Thanks for your inquiry.
With embOS, there's several options to perform periodic jobs within your application.
The most appropriate typically are the embOS software timers:
static OS_TIMER MyTimer;
static void MyTimerCallback(void) {
DoSomething();
OS_TIMER_Restart(&MyTimer);
}
int main(void) {
... // Initialization, etc.
OS_TIMER_CREATE(&MyTimer, MyTimerCallback, 50); // Create and start timer (period: 50 system ticks)
OS_Start(); // Start embOS
return 0;
}
If for some reason timers can't be used for the intended purpose (e.g. when specific API functions can't be used with software timers), another option is to make tasks periodic by calling OS_TASK_DelayUntil():
static OS_STACKPTR int MyTaskStack[128]; // Task stacks
static OS_TASK MyTaskCB; // Task control blocks
void MyTask(void) {
OS_TIME t0;
t0 = OS_TIME_GetTicks(); // Retrieve initial timestamp
while (1) {
DoSomething();
t0 += 50; // Increase timestamp by 50 system ticks
OS_TASK_DelayUntil(t0); // Delay this task for given period
}
}
int main(void) {
... // Initialization, etc.
OS_TASK_CREATE(&MyTaskCB, "MyTask", 100, MyTask, MyTaskStack);
OS_Start(); // Start embOS
return 0;
}Alternatively, you may of course use a hardware timer as well - it really depends on the intended purpose which of these otions fits best. If you can explain your intended purpose to us in a little more detail, we may gladly give some more detailed advice.
Best regards,
Martin
Hello kkmspb,
It seems you're increasing the stack size for one task. However, you'd need to increase the System Stack size instead. This can be done in the project options under "Code -> Runtime Memory Area -> Main Stack Size".
Best regards,
Martin