embOS PendSV_Handler exception

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

  • embOS PendSV_Handler exception

    Hi ,

    I have few question following using the embOS library , I tried working with the GNU/Atollic compiled library for Cortex M3 ( i.e no FPU ) using both :

    First Issue :

    libosT7L_DP.a for gnu toolchain ( Eclipse + GNU Tools ARM Embedded 4.7 2012q4)
    libosT7LDP.a for atollic studio 3.3.0 its 4.6.0 toolchain version i think .

    On both cases i received PendSV_Handler exception , i don't quite understand why because i don't have the lib source code and i cannot debug this issue.

    Following this problem , i switched to libosT7VLDP.a , the lib is intended for cortex M4F (off course i switched to my second evaluation board that is Cortex M4F) , then and only with this library (as the libosT7VL_DP.a for GNU had the same issue as above) ,i managed to get things working ( On Eclipse + GNU Tools ARM Embedded 4.7 2012q4 + libosT7VLDP.a).

    So this problem is solved for me , but i would love to hear how can i use the non FPU library because i will need it for the Cortex M3

    Second Issue :

    The Second issue is with dynamic allocation , when trying to do dynamic allocation it fails , and it does not matter if i try the regular malloc or OS_Malloc , but when disabling the embOS , the malloc works as expected , any ideas why does it happen? and how can i resolve this issue ?

    Thanks
    Michael
  • Hello Michael,

    Regarding first issue:
    embOS uses the PendSV Exception for the task switch.
    It comes with the PendSV Handler in the library.
    Thus you must not include your own PendSV Handler in your project.
    I don't know how you built your project, you should work with our start project, they work out of the box.

    Regarding second issue:
    Please be aware that the GNU heap managment for malloc() requires a lot of heap space defined in the linker file.
    Without having your project it's hard to say what actually goes wrong here.

    Best regards,
    Til
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.
  • Hello Til ,

    Regarding the first issue , i can surly tell you that i took the project as-is and just inserted it to Eclipse , i did not do any changes what so-ever , the issue was resolved only when i switched to the library compiled for atollic ( same code , different library).

    Regarding the second issue : the STM32F4G-EVAL comes with 128 kilobyte of internal RAM and 2 megabyte of external RAM , even if i am working only with the internal RAM , i still should enough of free memory to do a simple small allocation,
    And again i took the project as-is with no modifications what so ever , and just added in the task a call for malloc .

    If its possible i can send you the project , or at least the linker/startup scripts , but as i mentioned before , its the same project that you provided.


    Thanks
    Michael
  • Hello Michael,

    do you work with the latest embOS trial versions from our website?
    embOS CortexM Atollic V3.88
    embOS CortexM GNU V3.86i

    Which start project do you use for Cortex M3?

    The easiest way to evaluate embOS Cortex M for GCC compiler is to use embOS Cortex M emIDE.
    emIDE is a free IDE which can be downloaded from emide.org.
    embOS Cortex M emIDE can be downloaded from our website.

    Regards,
    Til
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.
  • Yes , this is correct.

    I think that i am on my way to fix the problem .

    it seems that setting in the linker script :


    _Min_Heap_Size = 0x19000; /* required amount of heap */
    _Min_Stack_Size = 0x200; /* required amount of stack */

    instead of :

    _Min_Heap_Size = 0x00; /* required amount of heap */
    _Min_Stack_Size = 0x200; /* required amount of stack */

    solves the issue .

    I am used to work on a bare metal system , where the _Min_Heap_size was not a issue , it seems that working with OS is different in this aspect.

    Thanks
    Michael
  • Heap managment with GCC can be different, it depends on where stack and heap are located in your RAM and how the sbrk() function is implemented.
    So it's less related to OS or not but moreover to the actual implementation.

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

    Regards,
    Til
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.
  • Hi ,

    First of all , i wanted to update that everything works correctly now , but i do have a brief follow up questions :

    Suppose calling OS_CREATETASK(&TCBTTS_PROCESS, "Main TTS Task", TTS_ProcessTask, 0xFF, StackTTS_Process);

    Is there a way to calculate the stack size i will need to execute the task , or should i just put a "rough estimate" of how much stack will my task consume ?

    Thanks
    Michael
  • Hi,

    yes, you could calculate the stack size because the stack size depends on how much subroutines are called and how much local variables do you have.
    You can also find a minimum stack size value in the CPU/compiler specific embOS manual.

    But the easiest way is to use a task stack which is large enough and check then with embOSView how much stack was maximum used.

    Regards,
    Til
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.