uisp-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Uisp-dev] TStk500::ReadByte() bug?


From: Theodore A. Roth
Subject: [Uisp-dev] TStk500::ReadByte() bug?
Date: Wed, 29 May 2002 11:04:58 -0600 (MDT)

Digging through the Stk500.C code, I see this:

  /* Read byte from active segment at address addr. */
  TByte TStk500::ReadByte(TAddr addr){

    if (read_buffer == NULL)
      ReadMem();

    return read_buffer[addr];
  }

I think there is a flaw in the logic here. read_buffer is a private member 
of Stk500 and is only NULL until the first call of ReadMem(), which 
allocates the buffer and fills it. After that first call to ReadMem(), the 
read_buffer seems to be set in stone since ReadMem() can't get called 
again and only read_buffer is only freed (deleted) by ~Stk500().

Now let's say I change the segmemt from Flash to EEPROM and call
ReadByte(), I get value from the old buffer.

I'm still digging through the code and don't yet see that this isn't the 
case:

  address@hidden src]$ grep -n -e read_buffer *.C /dev/null
  Stk500.C:163:  if (read_buffer == NULL)
  Stk500.C:166:  return read_buffer[addr];
  Stk500.C:314:  read_buffer = new TByte[GetSegmentSize()];
  Stk500.C:339:    memcpy(read_buffer+addr, buf+1, 0x100);
  Stk500.C:374:  read_buffer = NULL;
  Stk500.C:382:  delete read_buffer;

This...

  Stk500.C:374:  read_buffer = NULL;

is in Stk500() and this...

  Stk500.C:382:  delete read_buffer;

is in ~Stk500().

I'm going to perform surgery on this since I need it to work right to 
implement the reading and writing of the lock/fuse bits for the stk500. 

Any objections to just removing this "buffering optimization" and just 
implementing something that works?


Ted Roth





reply via email to

[Prev in Thread] Current Thread [Next in Thread]