Search Results

Hello Chu-Lih, the priority inversion is handled with priority inheritance which means that the low priority task is activated until it releases the resource semaphore. The scheduler will activate the low prio task TaskA() instead of the high prio task TaskB() when it detects that the resource is being used by another task. But this is completely handled internally so you will not see any modified priority in the tasks. Best regards, Til

Hello Rajbabu, which embOS do you use? CPU/compiler/version? Which start project do you use? Please don't modify the RTOS.h. There is no uart enable bit in RTOS.h Please find the embOS generic manual as also the CPU/compiler specific manual in your embOS shipment. You can find the embOS generic manual also here: embOS generic manual Best regards, Til

Hi Florian, Quote: “When I build my project with 'Release' Settings, it always works.” Are you sure that it works? OS_Error() is not called with release library because there is no debug code in release library. Quote: “After I have done this it also works for a while when I build with 'Debug' Settings.” Sounds strange to me. Quote: “Now I ran into the problem again and could identify what Task Ids changed. It was 'USBH_Task' and 'USBH_ISR' from the Segger emUSB lib. Have you ever seen this befo…

Hi Florian, The task control block includes the member "Id". The acutal debug check tests if the value in this member is still valid. You could set a watchpoint on this variable to find out when/where it is changed. Regards, Til

Hi Florian, Quote: “This only happens if I compile with debug settings, not with release settings (optimization turned on).” Do you use the embOS release library in your release configuration? The debug code is not included in the embOS release library. The application error still exists but there is no debug code which catches this error. Quote: “I'll look into that next but first I'd like to know more about this error and possible scenarios that could trigger this error.” This error means that…

Hello Bill, in general we send one month earlier a notification to our customers. In this case you should have received a notification from our U.S. office. I apologize for any inconvenience if you did not get the notification. Best regards, Til

Hello Marc, the actual data field content depends on the task status, but in general it's the address of the task wait list. This wait list is a linked list of all wait objects. In the case of e.g.: OS_EVENT _HW_Event; OS_EVENT_Wait(&_HW_Event); the wait list would include a wait object for _HW_Event. Best regards, Til

Hello, when you call OS_EnterRegion() without OS_EnterLeaveRegion() the region counter is set and preemptive task switches are disabled. In general cooperative task switches can still happen. But in case of OS_Delay() which calls internally OS_DelayUntil() the function waits active for the end of the delay when the region counter is set. So the answer is: No, other tasks will not be executed. Regards, Til

Hello, OS_Exception() is the old name for the embOS handler, we use now the CMSIS name PendSV_Handler() instead. The documentation is not up to date, thanks for the hint, we will correct it. The first 16 vectors are the same for all Cortex M3. Please find PendSV_Handler() below: Extraction from startup_stm32f10x_md.S: C Source Code (21 lines) The handler function itself is declared as weak which means that the Default_Handler is used when no other PendSV_Handler function exists. The embOS PendSV…

Hi Ashok, Quote: “in my code I have never reached OS_irq_handler() !! Any direction ?” That's the problem ;-). Quote: “ you mentioned OS_irq_handler() should get called but I can't see for which IRQ this irq hanlder should be assigned ?” I guess you replaced our startup code? Our startup code includes the vector table with the call to IRQ_Handler() at address 0x18. IRQ_Handler() is the embOS low level assembler interrupt handler which then calls OS_irq_handler(). If you use your own startup code…

Hello Ashok, you made several changes to the RTOSInit.c. Could you please try it again with the original RTOSInit.c? You removed for example the initialization of the interrupt controller, maybe you initialize it somewhere else but I can't know without having the complete project. You could also set a breakpoint at address 0x18 (IRQ) and step through the disassembly, do you reach the OS_irq_handler() function? If you like you can send us your complete project and I will have a look in it. Best r…

Hello Ashok, it's not necessary to call OS_EnterInterrupt()/OS_LeaveInterrupt() in your interrupt routine because it is already called in the OS_irq_handler() function. Without more information it's hard to say what goes wrong. Could you please give us some more information? Which embOS version do you use? Which CPU/evalboard and start project do you use? Did you make any further modifications to RTOSInit.c? You can also contact our support directly, sounds like it would be something which we ca…

Hello, Quote: “Is there any new configurations we need to consider for this part?” No, the only major difference between this device and other STM32F103 devices is the flash memory size. Could you please check if the linker file is set accordingly? Could you please send us your project so that we can try to reproduce this issue? Best regards, Til

Hello George, without having your code it's hard to know what could go wrong. In general the task with the highest priority which is ready to run will be executed. Could you please contact our support directly? Maybe it's possible to send us your project? Best regards, Til

Hello, we are not aware of any problems with task events. Could you please contact our support directly? Maybe it's possible to send us a project with which we can reproduce this issue? Best regards, Til

Hello Michael, the embOS FPU libraries are built with the GCC option -mfloat-abi=softfp. ‘softfp’ allows the generation of code using hardware floating-point instructions, but still uses the soft-float calling conventions. Please use the same option in your project, you can't use 'hard' with embOS FPU libraries. Best regards, Til

Hello, yes, the software timer callback functions are called by the scheduler, so they work only after OS_Start(). Best regards, Til

Hello, please have a look in the generic embOS manual. Each chapter includes a table which shows where each API function may be called. Yes, you can use OS_Delayus() in main() before OS_Start() is called. Please note that OS_Delayus() uses the hardware timer so it works only after the timer is initialized. Best regards, Til

Hello, there was an issue with OS_GetTime_Cycles() in some RTOSInit.c some time ago but should be now fixed in all RTOSInit.c. Could you please contact the embOS support via email? We can check then if you have the fixed implementation of OS_GetTime_Cycles(). Best regards, Til

Hello Todd, unfortunately we don't have such a document, but we measure the maximum interrupt latency caused by disabling interrupts internally. Please contact me via our support email address and I will send you the values. Best regards, Til