OS_Use leads to unexpected jump

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

  • OS_Use leads to unexpected jump

    Hello Segger-Forum-Team,

    I'm using the embOS for MSP430 and now have a problem by the use of the OS_Use method. For the time my LCD is used, the LCD shall be blocked for other tasks.

    C Source Code

    1. void lcd_Pwr(UBYTE ubParam)
    2. {
    3. UBYTE ubRetry = RESET;
    4. switch (ubParam)
    5. {
    6. case ON: // Turn LCD on
    7. if (OS_Use(&lcd_flag) == 1) //If sema taken by another task, wait. If sema is free, take it.
    8. { //If sema allready taken by this task, do nothing.
    9. LCD_PWR_ON();
    10. OS_Delay((OS_TIME)LCD_PWR_DELAY); // wait for power on
    11. /* (...) */
    12. }
    13. break;
    14. case OFF: // Turn LCD off
    15. LCD_PWR_OFF(); // power off
    16. OS_Delay((OS_TIME)LCD_PWR_DELAY);
    17. OS_Unuse(&lcd_flag); // flag lcd not in use anymore (-> LCD-Resource is free again)
    18. break;
    19. default:
    20. break;
    21. }
    22. }
    Display All


    The problem is now, that sometimes (not always and quite seldom) the PC jumps to a not executable area in memory during performing the OS_Use method. It looks a kind of a corrupted ret-address on stack, but I wasn't able yet to catch this issue in the moment it goes wrong. What I know is, that the program entered OS_Use but never came back properly.
    My question is, if taskswitches are performed during OS_Use, so that maybe another task corrups the semaphore or the stack of the task in charge? Can a corruption of the semaphore lead to an unexpected jump at all (I know it can make the task stop so far but cam it crash crashing)? Maybe You have an idea what can cause this behave.

    Thanks in advance and regards,
    Daniel
  • Hello Daniel,

    we are not aware of any problems with embOS MSP430.
    If another task overwrites the return address on stack this could happen.
    Could you please ensure that no data is overwritten (e.g. with Watchpoints)?
    How do you know that the crash happens in OS_Use()?
    Can you provide us with a project with which we can reproduce the issue?

    Best regards,
    Til
  • Hello Til,

    Thank you for your fast feedback.
    I used a soft debug trace which logged the executed lines of code into an array. I traced the line before and after OS_Use, but the line after in fact was never reached. So I thought the ret-address from the call OS_Use was corrupted somehow during execution. The question is, if during OS_Use another task may come in charge and interfer, or is a taskswitch not possible during this function?

    An indicator is in the project all tasks are running on same priority, except the one which is calling this LCD semaphore. This happened unintetional and will be changed anyway so really all tasks are running on same priority. In fact, I never had this kind of error when I do so - which doesn't mean that the error is fixed in this case and I don't believe that this is the issue.

    Actually we don't have a procedure or a way so far to reproduce this. It happens more or less stochastically one or two times a day, which makes it pretty nasty to debug.
    Due to security and copyright issues it's not possible to provide the full project to you. Anyway I can try to extract the piece of code from the rest, to see if the we can reproduce it seperately and provide it to you, if this is the case.

    Best regards,
    Daniel
  • Was there solution to this problem as I have the same kind of issue.

    This is the code:
    EE_DBG("here 1\n\r");
    EE_DBG("Owner %d\n\r",OS_GetResourceOwner(&Sema_I2C));
    ret = OS_Use(&Sema_I2C);
    EE_DBG("Owner %d\n\r",OS_GetResourceOwner(&Sema_I2C));
    EE_DBG("here 2 %d\n\r", ret);

    Debug print is this when the system fails:
    here 1
    Owner 0
    OsErr: 161

    And this when not (usually this case)
    Owner 0
    Owner 536936692
    here 2 1

    Best regards:
    Eero