This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

tsk_unlock issue/query

We have RTX 3.01 in a product on LPC2214.
We are attempting to isolate a problem whereby a task which is called by 'os_dly_wait' every 350 milliseconds, appears to 'stop' for over 30 seconds, usually after about 4 days running.
This question is to do with an experiment. We have written code which stops 'tsk_unlock()' from calling 'OS_UNLOCK()' (macro in our configuration)under a controlled condition for 30 seconds. The controlled condition definitely occurs, but suppression of 'OS_UNLOCK' appears to have no effect whatsoever on the system. Everything we have carries on normally. Why is this?
All suggestions gratefully received.

Parents
  • Many thanks for the reply. No joy with that line of thinking.
    Ths brings us back to the real problem. A task which runs every 350 milliseconds (triggered by os_dly_wait), works for a period (typically 4 days, but occasionally much less) and then does not run for 30+ seconds, before starting to run again.
    We are endeavouring to find a reason for this.
    Tasks in the system which are driven off ISR events, via PWM interrupts, and tasks which are driven off ordianry events from the ISR inspired tasks, do not exhibit this behaviour.
    (Our next step is to confirm if the problem is peculiar to one task, or applies to all the tasks which rely on os_dly_wait for activation.)

    Any thoughts or similar experiences at all would be welcome!
    Thankyou for taking an interest.

Reply
  • Many thanks for the reply. No joy with that line of thinking.
    Ths brings us back to the real problem. A task which runs every 350 milliseconds (triggered by os_dly_wait), works for a period (typically 4 days, but occasionally much less) and then does not run for 30+ seconds, before starting to run again.
    We are endeavouring to find a reason for this.
    Tasks in the system which are driven off ISR events, via PWM interrupts, and tasks which are driven off ordianry events from the ISR inspired tasks, do not exhibit this behaviour.
    (Our next step is to confirm if the problem is peculiar to one task, or applies to all the tasks which rely on os_dly_wait for activation.)

    Any thoughts or similar experiences at all would be welcome!
    Thankyou for taking an interest.

Children
No data