[Top][All Lists]
[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
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Uisp-dev] TStk500::ReadByte() bug?,
Theodore A. Roth <=