68k chip, Diab Compiler and odd behavior

sts_222@hotmail.com (Scott) wrote in message news:<2a55e2bc.0404120426.612818f9@posting.google.com>...
> sts_222@hotmail.com (Scott) wrote in message news:<2a55e2bc.0404090600.36d709b@posting.google.com>...
> > Let me first say that I am new to the embedded development community.
> > I have been tasked with determining the problem with the code below.
> > Let me explain what is happening and why I find it strange. The
> > problem is in the inner for loop. The first 16 times through the loop
> > all lines execute as expected. After that, when I step through with
> > the debugger, line 12 is executed and the debugger skips 13 and 14,
> > and goes to line 15. The debugger will not step into the function on
> > line 15, gScreenIO.Special(), it just pops out and goes to line 12
> > again to repeat the pattern.
> > 
> > I am using Diab Data 4.0b, SingleStep 7.03 on a Windows NT
> > environment. I have never seen this kind of thing before. I find it
> > quite odd. I have tried changing the data types of shiftcnt, shift and
> > count to the largest types possible; same behavior. We can't get any
> > help from Windriver (I think they bought Diab compiler) because we
> > haven't given them enough money.
> > 
> > Any help would be *greatly* appreciated. 
> > TIA.
> > 
> > 1void SetSysWin( void )  // Highlight all fault buttons //
> > {
> > 2  register _faults *fltptr = Disfaults;
> > 3  ulword tmpfaultvalue;
> > 4  ulword shiftcnt;
> > 5  ulword shift; 
> > 6  uword  count;
> >  
> > 7  for( count = 0; count < MaxFaults; count++ )
> >   {
> > 8    tmpfaultvalue = fltptr[count].faultvalue;
> > 9    if(tmpfaultvalue)// don't need to check all the bits if there is
> > no fault
> >     {
> > 10      for(shiftcnt = 0; shiftcnt < 32; shiftcnt++) // 16 bits to
> > shift through
> >       {
> > 11        shift = 1;
> > 
> > 12        if( ( shift <<= shiftcnt ) & tmpfaultvalue )
> > 13          if( ! ( fltptr->faultsalreadydisplayed & shift ) )
> >           {
> > 14            fltptr->faultsalreadydisplayed |= shift;  
> > 15            gScreenIO.Special(butPress, Faults[count][shiftcnt]);
> >           }
> >       } 
> > 16      gScreenIO << flush; // STS
> >     }
> >   } // end of for count loop
> > 
> > 17  return;
> > }
> 
> Thanks for the input gentlemen. 
> 
> I don't know why the programmer didn't use unsigned long instead of
> typedefing ulword. I thought the same thing when I saw that. Adds to
> the confusion. Along with the silly "16 bits to shift through"
> comment. 16 or 32?
> 
> I'll try and let you know what happens.
> 
> Scott


I don't know why the debugger was skipping lines 13 and 14 and going
to 15 and not executing, but know why my display was not being updated
correctly. tmpfaultvalue was being set to a mask of 65535 (0xFFFF). As
a result, the first 16 faults on the display were being updated. The
problem is that there are 19 faults on the display.

Scott