NetBurner Community Forum

Posted: **Fri Oct 09, 2009 7:14 am**

Does anyone know why my debugger would stop in the OSSched() at the line:

asm ("UCOSWAITS_HERE:")

Is there an issue with my task switching? For reference, the complete OSSched function is below:

Code: Select all

void OSSched( void )
{
   register volatile BYTE x, y, p;

   UCOS_ENTER_CRITICAL();
   if ( OSLockNesting == 0 && OSIntNesting == 0 )
   {
      y = OSUnMapTbl[OSRdyGrp];
      x = OSRdyTbl[y];
      p = ( y << 3 ) + OSUnMapTbl[x];
      OSTCBHighRdy = OSTCBPrioTbl[p];
      if ( OSTCBHighRdy != OSTCBCur )
      {
#ifdef    UCOS_TASKLIST
         volatile DWORD *pStack = ( DWORD * ) OSTCBHighRdy->OSTCBStkPtr;
         OSLogTaskPos( OSTCBHighRdy->OSTCBPrio, pStack[16] );
#endif

		 OS_TASK_SW();
         asm (".global  UCOSWAITS_HERE");
         asm ("UCOSWAITS_HERE:");
//******************************
// DEBUGGER STOPS HERE:
         if ( OSShowTasksOnLeds )
         {
            putleds( ( unsigned char ) ( OSTCBCur->OSTCBPrio ) );
         }
      }
   }
   UCOS_EXIT_CRITICAL();
}

Posted: **Fri Oct 09, 2009 7:10 pm**

If you just kit the stop/pause button, it will stop where ever it happens to be. I think it may have been you who had a previous ticket on setting the pc to some value, which I think is a very bad idea because interrupting the normal flow of code can cause memory issues. So a lot depends on how you got there, used the debugger to change any variable values, paused the application long enough for tcp sockets to time out, etc. Stepping through code or pausing code on a system that interacts with outside connections that can request retransmissions or timeouts can create issues that would not be there otherwise.

Posted: **Mon Jul 04, 2011 5:07 pm**

I am seeing the exact same issue as the original poster, after simply starting my SB72-based application under the debugger. No breakpoints are enabled, I have not tried changing any variables or registers, just running the code. If I hit "Go", the code will run for a short while and then stop at the same location again. It's like there's a breakpoint set in this code, even though I have verified that all breakpoints are deleted. Any ideas?

-David

Posted: **Tue Jul 12, 2011 7:28 am**

Hi David,

Have you resolved this?

I see this if there is any crash in one of the tasks I have running. It makes tracking it down a little harder.

What I do is look at the debug window where the list of tasks if located (normally top left) and check each one in turn to see where it has paused. Generally the task with the corruption is the one that is no in OSSched. This has been the case for me until recently when I am still trying to track down an elusive memory bug.

Dave...

NetBurner Community Forum

Debugger stops OSSched() at: asm ("UCOSWAITS_HERE:")

Debugger stops OSSched() at: asm ("UCOSWAITS_HERE:")

Re: Debugger stops OSSched() at: asm ("UCOSWAITS_HERE:")

Re: Debugger stops OSSched() at: asm ("UCOSWAITS_HERE:")

Re: Debugger stops OSSched() at: asm ("UCOSWAITS_HERE:")