tsk_lock causing a hard fault when called from an ISR

The ISR doesn't need any task lock since the OS will not perform any potential task switch until the ISR ends.

And since an ISR can happen when different tasks are active, it would be strange for an ISR to try to play with running tasks. The normal interaction between an ISR and tasks is that an ISR uses any of the isr_xx() functions to inform the scheduler that it needs to reschedule when the ISR ends - for example that the ISR have received serial data and that there may be a very high-priority task waiting for serial data to process.

Another thing an ISR can do is play with interrupt sources - for example deactivate some interrupt sources. However, that should be avoided since it makes the code harder to read and test. Interaction between different ISR should be handled by normal interrupt prioritizes while interaction between an ISR and other tasks should be handled with the isr_xx() functions.

I fully agree with what you have mentioned.
My ISR setup the stage and exit. The difference is that the setup consists on setting some global variable, disables ALL TASKS and all interrupts sources (except for a single interrupt source that services a time critical external device) so that my critical code can run un-interrupted.

The task that is giving me grief waits on event (the standard case) or it can timeout after a certain number of clock ticks i.e. it can start without an actual event. Even that small delay that is the Cortex uses to restore and save the task could have an impact on my time critical code.
This is why I was looking for ways to disable the tasks.

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.

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.