We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Hi everybody, I have a question related to implementation of tsk_lock() for Cortex-M3. The manual says that the function disables the timer interrupt and thus prevents the RTOS from switching. But disabling the interrupt and clearing a pending interrupt flag are sometimes completely different things. Calling tsk_lock() and immediately after it calling tsk_ulock() should not drastically modify application behavior. What we found is that if the timer interrupt is due to happen between the calls of tsk_lock and tsk_unlock, the interrupt will be lost regardless of how quickly you call tsk_unlock. Which to me is an error - the tsk_lock should only disable the interrupt but keep the pending flag, so that the ISR is called immediately after tsk_unlock. Otherwise tasks that are waiting on os_dly_wait will miss a beat. Which is what we see. Can anybody comment on it and tell me if this is how it was designed? Thanks.
The tsk_lock() and tsk_unlock() are never used in RTX for Cortex-M library. Both functions are there for compatibility reasons with ARM library.
Instead of tsk_lock/tsk_unlock you might consider using __svc functions. They are never interrupted by RTX kernel.
Frank, why __svc functions? And why are the tsk_lock and unlock never used in RTX for Cortex-M? They seem to be doing what they are supposed to do with the exception of clearing the pending flag upon exit? The only reason why I use them is because I need to protect a critical section of a low-priority task from being preempted by another, higher priority task. I thought that calling tsk_lock and unlock was the easiest way of doing it, compared to raising the task priority or disabling global interrupts. Can you point me to how I can use _svc functions to prevent RTOS from task switching in a critical section of code? Thanks. Sergey