DSP/BIOS UTL_halt when Starting Task on DM6437

Try setting a breakpoint at the start of that task.  Look in the disassembly window to see if valid code is there.  If you see any ".word" in the disassembly window at this function location then it's likely that the memory area has been corrupted.

I have tried setting the breakpoint at the start of that task.  It never reaches the breakpoint.   Whenever a previous task sleeps, or yields, the PC jumps to the UTL code and I get the error messages in the execution details.   I tried adding a sleep earlier and it just jumps to halt at that earlier point.

Anything else I should try?

Thanks,

B

In the original error message it gave an address for NRP.  That's the address where it executed the illegal op-code.  Please look at that address and see if you can make any sense of it.  For example, is it a valid function, but the code was corrupted with junk?  Did some other function "jump into the weeds" and cause you to land there?  There's also a "call stack" option in CCS.  Just go to View -> Call Stack.  Sometimes it provides really helpful info and other times not so helpful.  I guess it depends on if the stack is still intact.  Speaking of stack, try opening DSP/BIOS -> Kernel Object Viewer.  That will allow you to see if you've overflowed a stack.

Brad

More info... DSP/BIOS v5.33 

The very first task switch to this Task, the BIOS never gets there.   

In short, TASKA hits a TSK_sleep() which allows it to task switch to TASKB.  The execution graph shows this entering TASKB though the breakpoint in Task B is never reached.  I cannot step over the sleep.  Code jumps to halt when I break.  The execution graph shows a semaphore error.  

The tasks are statically assigned in the TCF file.  They both had the same priority, though I also tried with TASKB with a lower priority.   

The NPR code is pointing at a LOG_ buffer, TaskA stack seems okay.   Could this be a problem setting up the tasks so that BIOS finds them.  I should mention that the TaskB is in a CPP file, but I got it to link so I believe that I am good to go. 

Did you use "extern C" for the function in the C++ file?  Usage of BIOS with C++ is discussed here:

http://processors.wiki.ti.com/index.php/Overview_of_C%2B%2B_Support_in_TI_Compilers#BIOS_and_C.2B.2B

PS.  Why the 5 year gap in responding?!?!  :-)

Yes.  I declared the function like this;  It wouldn't compile before I added this.  I also added the task as _threadDisplay in the tcf editor.   Its now a run-time problem.  

Maybe I'm forgetting something else about adding a new task using the tcf editor? 

#ifdef __cplusplus
extern "C" {
#endif

void threadDisplay(void); 

#ifdef __cplusplus
}
#endif

As for your PS.  Five years ago I decided to rewrite a dynamic thread as a static thread so that I could get more debug info from the CCS Tools.   We found the bug without it, so I moved on.   We are debugging a current issue, and I had the same great idea and ran into the same problem!   Thanks for your help.   

A couple ideas come to mind...  One might be to look at the state of things in ROV just before the context switch that would activate the task.  The intent would be to look for anything "odd" because it seems like something is messed up.

Another easy test would be to make this failing task the very highest priority task in the system (just as a data point).  The highest priority task is the first one that gets to execute after BIOS_start, so this would at least test that it is possible for that thread to run! 

Another thought... Recent versions of CCS have a "verify" option under the "Run" menu (i.e. instead of "load" you can do just the "verify").  Perhaps you could try that out just before the task switch to see if something has been corrupted.