DSP/BIOS DM6437 SYS abort LOCK NOT CALLED IN TSK CONTEXT

There is a function callability table in appendix A of SPRU403o that shows what you can call where in a BIOS application, in this particular case it sounds like you may have put SEM_create in a context that is not a TSK, essentially SEM_create cannot be safely be called by a SWI or HWI.

The reason is because SEM_create calls a MEM_alloc which will lead to a LCK_pend call that could block and cause a context switch which cannot happen in a HWI or SWI as the scheduler is disabled, this would mean the system is halted, which is why you get the "LOCK NOT CALLED IN TSK CONTEXT" error.

I am not calling it from a HWI or SWI.  Its just a userspace application.  Maybe I'm stomping on the handle.   Should I expect a different error if that was the case?

If the handle or internal data structures are corrupted you could get anything, but the most common cause for this particular error is calling a function that should not be called in a particular context. You could also get this if you disabled the scheduler in the task that you are calling this from. If you are worried about corruption it may be worth increasing your stack and heap space to see if that has any effect.

Is it really just the adding of this one function that is causing the error, or perhaps adding this is inadvertently leading to an incorrect call in another piece of code? It has been a while since I worked with one of these errors, but it seems very strange that it does a post to the KNL_swi (the task scheduler) when it triggers this, along with it running for a minute first which is also strange, it is possible that you are seeing some corner case bug in BIOS. If it turns out this is the case it may be worth upgrading to a newer BIOS version to see if the behavior changes or goes away.

I didn't intentionally disable the scheduler.    Is there anything in the system that does this automatically?

Heap sizes seem pretty good.  It runs 539 times before failing.

This is what I have for code.   Maybe there is something I don't see. This is a generalized version however it captures what the code is doing (i.e. the struct has other entries, and declares the structure correctly, a TSK calls SEM_lock()).  Also note that I don't see an assert when it crashes.   

I also tried statically creating the SEM instead of the dynamic below.    It gave a different error and I'll retry that and report back.

FILE A
-------------------------------

include "mySem.h"

BOOLEAN SEM_lock(semInfo sInfo)
{
   assert ( sInfo->semLock == SEM_Write);
  
   if (!SEM_pendBinary(sInfo->semLock, SEM_WAIT_TIMESTAMP_TICS)) {
     printf("%s SEM Timeout", __FUNCTION__);
     return FALSE;
   } 
   return TRUE;
}

mySem.h

---------------------------------

typedef struct SEM_INFO {
   SEM_Handle semLock;   // Only needed by the DSP.
} semInfo;

Bandeg said:

I also tried statically creating the SEM instead of the dynamic below.    It gave a different error and I'll retry that and report back.

If you still get an error relating to an incorrect context call when creating the SEM statically than perhaps there is something elsewhere that is causing the trouble, I am curious what the alternate error is.

After running the static case again, it crashes with the same error as the dynamic case.    I think previously I had something wrong with the static case because it died on the first call.

Can you think of anyway to pinpoint the problem?    (This is the same code that I am having problems with the new BIOS version, noted on a different thread).    Could there be a larger BIOS problem here?