MEM_free() blocks forever

 Make sure you're not overwriting past the end of the block (or before the beginning - rarer).

If you have multiple threads (TSKs) that are using MEM calls on the same memory segment than calls to MEM_free are no longer as deterministic. When you call MEM_free it will attempt to obtain a lock (LCK_pend) on the memory, so if another task already has the memory locked than the MEM_free call will block causing a context switch, remaining blocked until the task that owned the lock releases it (LCK_post). Because of this you can end up with a higher priority task blocking while lower priority tasks run until the lock is released (priority inversion!). You can get around this by carefully selecting memory segments for MEM such that only tasks of the same priority use the same segment, or by temporarily raising the priority of a task that is calling MEM_free during the call (TSK_setpri).

In an even worse case if you call MEM_free from a HWI or SWI and the lock is not available you will halt the system, since the scheduler is not running while in a HWI or SWI if you try to block you will effectively block forever (this is one of the ways you can end up in SYS_exit). You can get around this by avoiding calling MEM_free in a HWI or SWI context (post a high priority TSK to make the call if you have to).

 All of these BIOS APIs are discussed in the document below for reference. http://focus.ti.com/lit/ug/spru403o/spru403o.pdf

 Hi,

 Sorry for late response and thank you for your help.

I checked for the reasons mentioned but they're not the case. Although I found that I sometimes I would try to free a memory location that was created statically (the head of linked list), resolving the problem results a much slower program but with less chances of blocking forever!

I am opting for a different implementation that avoids dynamic memory allocation now. Although the code I wrote works perfectly fine when I remove MEM_free but eventually I run out of memory. Number of MEM_alloc is larger than MEM_free operations and they it doesn't cause any problem! MEM_free runs continuesly every 10 frames to do garbage collection for unwanted memory locations, might this be the reason?

I found that MEM_free either spends alot of time or stop at the following assembly code:

830F30F0 6C6E                     NOP                4
830F30F2 A0C6                     MV.L1             A1,A5
830F30F4 20940264     [ B0]   LDW.D1T1      *+A5[0],A1
830F30F8 4C6E                     NOP               3
830F30FA 06A7                     MVK.L2          0,B5
830F30FC EA202000            .fphead             n, l, W, BU, nobr, nosat, 1010001
830F3100 021740F0 ||            MVD.M1         A5,A4
830F3104 0627                     MVK.L2           0,B4
830F3106 2DC8     ||             CMPLTU.L1     A1,A3,A0
830F3108 828000AA ||  [ A1]  MVK.S2         0x0001,B5
830F310C C204A35A   [ A0]  MVK.L2         1,B4
830F3110 02148F7A             AND.L2          B4,B5,B4
830F3114 0247                    MV.L2             B4,B0
830F3116 2C6E                   NOP                2
830F3118 00000000             NOP           
830F311C E440000C            .fphead            n, l, W, BU, nobr, nosat, 0100010
830F3120 00034000             SPKERNEL      0,0

I abandoned the current implementation, but I would appreciate if anyone can help understanding the problem.

When you were saying that MEM_free blocks you were meaning that it is getting stuck in the MEM_free call (same task still executing), not that it blocked meaning a context switch to another TSK happened? If it is stuck in the same call than that seems a bit more suspect, as far as I know the call to MEM_free itself should not take very long so if it is not quick my first thought would be that it might lock up if it was passed incorrect parameters. I have not come across this sort of thing happening in the past, but assuming it is being passed the correct parameters you may want to try moving to a newer version of BIOS (available from the update advisor menu of CCS) to see if that has any effect on the issue.

As to running MEM_free periodically every 10 frames that should not be a problem at all as long as the proper values are being passed into MEM_free, and it is called in the proper context (from a TSK).

Yes I meant stuck. Sorry for using the wrong word.

It occurred to me that I am passing the wrong parameters but traced my code significantly to find if there's a logical mistake that causes a parameter to become invalid at some point, but couldn't find it.  I am checking every MEM_free call's result for correctness, and no failure was encountered yet! The presence of a mistake looks very logical for me although I can't find it after days of debugging. Specially that the code works fine without MEM_free.

Anyway, upgrading to 5.32.03 didn't solve the problem. I will see if another update is available.

I will post the cause if I could find it. Thank you for your help.