static tsk object in dspbios

Did you resolve this issue?  It wasn't clear from your description what was going on.  It sounds like your fundamental problem is a linker error?

Hi,

It was a linker problem because when you make changes in DSP/BIOS configuration tool, it keeps the old configuration in the scrpt  Now it 's ok , I suppressed the line bios.TSK.instance("TSK0").fxn = prog.extern("Uncomp", "asm");

In the first place, it was a memory allocation problem. If I try to compress/uncompress image larger than 1Mo with my codec, It doesn't work, most of the time, it freezes in MEM_free, so I thouht about using task but it's not better at the moment. 

Any help is welcomed

CC

You should definitely only be calling the MEM_alloc/free functions from a task.  So did you get that working?  I believe your issue was that you forgot to put a leading underscore in the bios config GUI.  For example if your function is called "myfunc" you need to enter the symbol as "_myfunc" since you are entering the assembly label.

Hi brad,

 I got the task working but I still have the same problem, the application freeze in a MEM_free call. The strange thing is that it happens only with images larger than 1 MB.

It works fine for some delete in my application but not far from the end of uncompressing process (I wasn't able yet to find where from is the MEM_free call )  it freezes in MEM_free.

CC

What do you mean by "freeze"?  That the call to MEM_free() never returns?  Is the entire application aborting?  Do other tasks continue to run?

Yes the call to MEM_free() never return. I have only one task running, so the entire application is stopped.

The only thing I can think of that would cause this problem would be if your MEM free list is somehow corrupted.   MEM maintains a free list of available memory.   This list is sorted by address.  MEM_free() traverses this list looking for the right slot to insert the free block.  If the linked list is corrupted (bad memory write by some other part of the application), then the free list could be inconsistent and might even have a loop so MEM_free() will loop forever.   Can you try using Kernel/Object View  (KOV) (if you are in CCSv3) or the ROV (runtime object view in CCSv4) to inspect the MEM module?   These tools will show you the status of the MEM heaps.  If the heaps are corrupt, these tools will generate an error.   Check the state of the MEM heaps at main(), and again right after you alloc the big block, and again right before you call MEM_free().

Along the lines of what Karl mentions, here is an entire wiki page devoted to various issues that commonly cause unpredictable behavior in the program:

http://processors.wiki.ti.com/index.php?title=DSP_BIOS_Debugging_Tips

Let us know if you have found the root cause yet.

I checked the heap with ROV and everything seems ok untill the MEM_free() call

I get this message after bieng stopped in MEM_free()

Received exception from ROV server: "baseAddr" is undefined (C:/Program Files

I suppress the delete that causes the MEM_free() crash and now my application crashes somewhere else, although it was running fine with smaller image.

There  are many stange things :

it works fine with smaller images (1MB) 

with large images it doesn't crash at the first call of this delete or others delete 

application using new and delete  not called from a task runs well with small image (1MB) 

It looks like something is corrupting the heap.   Is is possible to make a test case and attach as .zip file to this forum so that we can build and run here?  Will your app run on a standard EVM?

What is the size of your alloc and free?   Can you verify that the size parameter that you pass to MEM_free() matches the size parameter you passed to MEM_alloc()?  And that the 'ptr' parameter to MEM_free() is same as the ptr returned from MEM_alloc()?

Thanks,
-Karl-