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_lock causing a hard fault when called from an ISR

Hi,
I'm running RL-ARM and uVision4 4.14.4.0 on a Cortex-M3 (LM3S9B96)
I'm running several tasks and I want to temporarily disable them while a critical section of the code is running.
As far as I can tell (when I step through the code), tsk_lock( ) is causing a hard fault when called from an ISR.
I checked the documentation and did not see any restrictions.
Am I missing something?

khaled.

Parents
  • But you have realised that isr_xx() functions are the only OS functions you may call from an ISR?

    Disabling tasks doesn't help you. You still needs to activate your time critical task. So if it isn't running, you do need a task switch. And you can get that by making this task the most prioritized, and then have your ISR wake it. The other tasks will not interfere as long as they have lower priorities.

    If the task switch times are too long for your requirements, then you must consider that you have the wrong hardware or that you should use multiple processors.

Reply
  • But you have realised that isr_xx() functions are the only OS functions you may call from an ISR?

    Disabling tasks doesn't help you. You still needs to activate your time critical task. So if it isn't running, you do need a task switch. And you can get that by making this task the most prioritized, and then have your ISR wake it. The other tasks will not interfere as long as they have lower priorities.

    If the task switch times are too long for your requirements, then you must consider that you have the wrong hardware or that you should use multiple processors.

Children
  • Per, I really appreciate the time and effort that you are putting into this.

    One correction. I'm not running a task for my critical code. I'm running an ISR for my critical code.
    All interrupt sources (except for one, the one that is critical) and all tasks are disabled.

    My observation: if the tasks are not disabled, that task that is scheduled after timeout uses cpu resources that delays the servicing of the the critical ISR. That tiny delay IS an issue and I want to take it out.

    Changing the processor is not an option, we are close to the end with this project and I don't want to restart a new project to get around a task.

    Now, my question has not changed, I still need to disable the tasks.
    So why tsk_lock does not work from an ISR? and if there is a limitation, could I use something else?
    thanks.
    khaled.

  • that task that is scheduled after timeout uses cpu resources that delays the servicing of the the critical ISR

    No, it quite certainly doesn't. What exactly do you think your CPU will be doing between the end of that first interrupt and the start of your "critical" ISR, if not run some code? What makes you believe that changing what it's doing in that time will have any effect whatsoever on how fast your critical ISR comes up?

    Or for that matter, why is that oh so critical stuff in an ISR? What's keeping you from just calling that critical code directly from the ISR you're already in?

    I still need to disable the tasks.

    No. You still think you need to do that, but I'm pretty sure you're wrong about that.