unknown semaphore pend

The last thing to occur in the event logger before the bad context error 

is  "LM_pend: sem: 0xc007bfec, count: 0, timeout: -1".  

I see lots of these entries in the logger, but it seems like the last pend is somehow not in a task?

This semaphore has an unknown event class, it doesn't have any data to tell me what it is. it does not appear in my ROV, and I cannot find any reference to it in the map file other than

c007bea8 00009db0 optimus_realtime_pe674.oe674 (.far) <--- located somewhere in here

How does one figure out what this semaphore is?

Chris Roed said:

Sysbios 6.37.00.20

BiosPSP 3.00.1.0

Just some background, I'm using Mcbsp with issue/reclaim GIO model to aquire a signal from an ADC.  I have a heapBuf declared where I allocate a block, and pass the data to a DSP algorithm, which frees the memory after I've processed it.

I'm getting a "ti.sysbios.heaps.HeapBti.sysbios.knl.Semaphore: line 207: assertion failure: A_badContext: bad calling context. Must be called from a Task." error during runtime.

It seems the cause of this is usually due to having a Semaphore_pend in a SWI or a HWI.  I've searched my project and all of my Semaphore_pend calls are located inside tasks.  When the execution terminates, the ROV tells me that the thread type is Main.  

I'm not sure if this is the source of the issues you are observing, but one thing to note about HWIs and SWIs is that they are meant to run to completion and not be blocked with a Semaphore pend operation.  If you are getting the above error, I would suggest eliminating this as it may mask other issues.

Brandon, 

None of the semaphores that I declare are pended inside SWIs or HWIs.  They are all located within tasks.  It looks like the semaphore in question is one that is generated by SYSBIOS, and I cannot find the name of it or what it is associated with.

-Regards,

Hi Chris,

Do you have Hwis or Swis created in your app?  If so, what types of operations are you performing in their ISRs?

Steve

Chris Roed said:

None of the semaphores that I declare are pended inside SWIs or HWIs.  They are all located within tasks.  It looks like the semaphore in question is one that is generated by SYSBIOS, and I cannot find the name of it or what it is associated with.

Ah, I see.  I misread your original statements.

Steve,

I have one SWI that posts a semaphore for a heartbeat clock to run.

I have one HWI.  It's a trigger line to collect a sample on the ADC.  It posts a semaphore to unblock a mcbsp capture task. 

These are both posting sems, not pending them.  There shouldn't be an issue.

This issue has something to do with how long my algorithm takes, and thus how many ADC samples come in while I'm still processing the old data. 

At max, the algorithm takes 7ms, and during that time, the HWI I mentioned above triggers 3 ADC samples into a Q.   The computation counter reaches 15 until I get the error... however... after the algorithm is finished, the code seems to handle those Q entries correctly with plenty of time until the next sample arrives, the Q count is back to 0, memory allocated on sample heap is back to 0, semaphore count is back to 0.  

I changed the compute time so that 2 (sometimes 3)  ADC samples are collected during computation, there are 30 to 31 counts before the error.

If 1  ADC sample is captured during compute time,  there's 60-63 counts before the error.

If the computation completes before the next ADC sample, the error does not occur.

right now, the task that does the computation is the same task that pulls data off the Q.  I going to try to split them into 2 separate tasks to see if that helps.

That seemed to fix it.

This is the new exec graph.  

This fails when the algorithm thread also averages the 8 samples.  Can there be problems if a semaphore is posted 2 or 3 times before it pends?  Originally, the algoSem was being posted with every sample that was received, and depending on a state machine it would either average the samples, or run the algorithm.  According to my ROV,  the algoSem count got to 2 at the end of the algorithm,, but always returned to 0 so I figured it was being pended properly.

How does this cause SYSBIOS to throw an error that says that a semaphore was being called outside of a task?