Search Results

Dear Ran, __stack_start_ and __stack_end_ are linker symbols which are used by embOS. Which linker file are you using? With Embedded Studio the GCC linker file is generated from the flash_placement.xml and nRF52840_xxAA_MemoryMap.xml when you build the project. You might want to copy the Start_nRF52840.ld from the \Output folder to e.g. the \Setup folder and use it from there. Does that solve your issue? Best regards, Til

The web page is wrong but the embOS manual is correct. We will fix that on the web page now. Thanks for the hint! Best regards, Til

Thanks for the additional information. I'll contact you per email for further steps. Best regards, Til

Which problem? I can see in your screenshot that you are calling OS_PutMail() from an ISR which is not allowed. Please use OS_PutMailCond() instead. Does that solve your problem?

Hello Alex, please understand that it will be hard to help you with this little information. To help us and other forum members to understand your issue you should include at least the following information in your post: 1. Which embOS do you use? (CPU, compiler). 2. The embOS version. 3. A detailed description of the problem. Btw. since your are still in support please feel free to contact us directly by email. Best regards, Til

Ok, in that case you'll need to modify the MMU table accordingly since this memory region will most likely be missing. In case of doubt please contact us directly by our support email address. Best regards, Til

Hello Arul, it should not be necessary to change the selected target. Did you update the MMU table according to your device/hardware? Are you using one of our BSPs or did you create it on your own? embOS ARM IAR comes with board support packages for various SAMA4D3x boards. Best regards, Til

The IAR device definition file uses addresses at 0x3FEFA000: C Source Code (15 lines)This memory region is not mapped per default in our MMU table. But you can easily add an according entry to it: OS_ARM_MMU_AddTTEntries(_TranslationTable, OS_ARM_CACHEMODE_NC_NB, 0x3FE, 0x3FE, 0x001); // IO Area Please note you have to reduce the previous section size accordingly: OS_ARM_MMU_AddTTEntries(_TranslationTable, OS_ARM_CACHEMODE_ILLEGAL, 0x214, 0x214, 0x1EA); // Reserved area In case of doubt I can al…

Thanks, we'll have a look into it. Best regards, Til

HI Allan, I just did a quick test with a memory window and it looks ok. The SPI multi I/O BUS space 1 is at physical address 0x18000000 and is mapped to the same virtual address 0x18000000. The cache setting for this memory region is set to write through. The cache settings respectively the complete MMU table depends on your needs, so you might want to use strongly ordered instead of write through which would be OS_ARM_CACHEMODE_NC_NB. You are still in support, thus please don't hesitate to cont…

Hello PTepe, just two additional notes: 1. Overflow is no problem for all our timeout functions like OS_TASK_Delay(). It simply works! You can also use it for yourself as long as you are working with signed subtractions between two OS_GetTime32() values. 2. If you just need the absolute system time after reset you can also use OS_TIME_Getus64() which returns the current system time in microseconds as a 64 bit value. With this 64 bit value OS_TIME_Getus64() can return up to 18446744073709 seconds…

Could you please contact us per our embOS support email address and share your company name, embOS license number and your project with us? I think that makes it easier. Thanks, Til

Correct, the STM32F303 has 4 priority bits implemented. The actual priority register has 8 bits and the 4 lower bits are always zero. That means you can have the priorities 0x00, 0x10, 0x20...0xF0. Interrupt priorities below 0x80 arre zero latency interrupt priorities and anything else is an embOS interrupt priority. Please have in mind with Cortex-M lower value means higher priority, e.g. 0x00 ist the highest interrupt priority. Best regards, Til

Quote: “// Set the Interrupt Priority and Sub-Priority I_STM_NVIC_SetPriority(TIM3_IRQn, 04, 00);” Most likely that causes the problem but depends on how much interrupt priority bits are usable in your actual device. Could you please have a look in the CPU/Compiler specific embOS manual in chapter "Interrupts". Basically embOS splits the Cortex-M interrupt priorities in two parts: embOS interrupt priorities and zero latency interrupt priorities. embOS API can be called from interrupts with embOS…

Hi, are you using a valid embOS license or an embOS trial version? I am not sure if I understood your code snippet correctly. 1. Where do you call OS_SignalEvent()? 2. What is the last function before OS_Error() in your call stack? Basically this error message tells you that an embOS API was called from an invalid CPU state. That could e.g. happen with Cortex-M when your ISR routine used an invalid interrupt priority. I guess you are not using embOS ARM IAR but embOS Cortex-M IAR, correct? Best …

I think that question is more related to Rowley Crossworks than embOS. Did you change the linker file accordingly? Could you please share that with us? I will also check whether we can provide a sample project or linker file. Btw. As you are still in support please don't hesitate to contact us with the embOS support email address. Best regards, Til

Hi Lior, did you make any changes to the board support package, especially OS_GetTime_Cycles()? I'll check if we have the same device/evalboard here and give it a try. But I am pretty sure it should work as expected. Best regards, Til

Hi Axel, no, there is unfortunately no easy way and I don't think you example will work like that since you have only declared a pointer but not the variable itself. Usually it would be something like: OS_RSEMA sema; OS_CreateRSema(&sema); But &sema has also a valid value before OS_CreateRSema() . With the debug build of embOS you could check sema.Id which gets a valid value when the semaphore is created. But this Id member is only available in embOS debug builds. Best regards, Til

Hello Santhosh, I don't know which device you are actually using but it should work the same with embOS. embOS does not have any influence on your DMA or Uart. IRQ interrupts are handled via embOS with a low level interrupt handler in assembler and a high level interrupt handler in your RTOSInit.c. Could you please check your MMU table in the RTOSInit.c? It defines which memory regions are cached. That could be an issue because the DMA writes directly to the memory and you are maybe just reading…

Hi Kenny, OS_EnterInterrupt() disables interrupts with setting BASEPRI register to 0x80 which disables all embOS interrupts. OS_EnterNestableInterrupt() does not change the BASEPRI register and therefore does not disable interrupts. Quote: “Are OS_EnterInterrupt and OS_EnterNestableInterrupt effectively the same on Cortex-M? ” Yes, they also work with Cortex-M. The macro is not necessary in all embOS ports. The interrupt handler could be preempted before OS_EnterInterrupt() is actually called bu…