Menu
▾
▴
rcxemul-discussion
|
From: David E. <d.a...@du...> - 2002-10-18 23:22:20
|
I'm hot on the trail of the reason why the firmware won't unlock. I've discovered that the last time I tried it, there was only one byte in the entire firmware transferred wrongly. This put the checksum off by 8: Expected 0xA000 77 79 1E 11 1E 88 1E 00 0D 42 1D 20 47 1E 6E 6A Observed 0xA000 77 79 1E 11 1E 88 1E 00 0D 42 15 20 47 1E 6E 6A Note that we have 1D in the expected firmware image, and 15 in the observed. I have no idea why! I've traced through the tons of debug information that I have and I'm still at a loss. 0x1D is definitely the value that gets transmitted by the firmware downloader, but 0x15 is being written. I'm going to try again to see if it's the same byte that gets written wrongly. If it is, I'm going to have to trace the receive handler for that particular byte to see why it's not getting set correctly. |
|
From: Andy G. <gom...@ea...> - 2002-10-19 00:05:42
|
0x1D may be written to the socket, but are you sure that is what is coming out of the other end of the pipe? Let's say you slightly corrupt your memory (I haven't looked at the code, so I don't know how you allocate memory and control it), and this corruption is apparent only on this byte, producing (since the program/rom is running through the same sequence each time) a reproducable error in the socket memory buffer only on this byte. Assuming the socket recieve buffer is not corrupted, the firmware buffer the final byte is added to may be. Again, I haven't looked at the code or been able to get the firmware to download, so you may be printing out all recieved bytes. This is why I hate straight C. ----- Original Message ----- From: "David Edwards" <d.a...@du...> To: <rcx...@li...> Sent: Friday, October 18, 2002 7:22 PM Subject: [Rcxemul-discussion] Strange things afoot > I'm hot on the trail of the reason why the firmware won't unlock. I've > discovered that the last time I tried it, there was only one byte in the > entire firmware transferred wrongly. This put the checksum off by 8: > > Expected > 0xA000 77 79 1E 11 1E 88 1E 00 0D 42 1D 20 47 1E 6E 6A > > Observed > 0xA000 77 79 1E 11 1E 88 1E 00 0D 42 15 20 47 1E 6E 6A > > Note that we have 1D in the expected firmware image, and 15 in the > observed. I have no idea why! I've traced through the tons of debug > information that I have and I'm still at a loss. 0x1D is definitely the > value that gets transmitted by the firmware downloader, but 0x15 is > being written. > > I'm going to try again to see if it's the same byte that gets written > wrongly. If it is, I'm going to have to trace the receive handler for > that particular byte to see why it's not getting set correctly. > > > > ------------------------------------------------------- > This sf.net email is sponsored by: > Access Your PC Securely with GoToMyPC. Try Free Now > https://www.gotomypc.com/s/OSND/DD > _______________________________________________ > Rcxemul-discussion mailing list > Rcx...@li... > https://lists.sourceforge.net/lists/listinfo/rcxemul-discussion |
|
From: David E. <d.a...@du...> - 2002-10-19 00:29:08
|
The error is repeatable. I tried again and exactly the same byte was written incorrectly as 0x15. When the emulator receives a packet, for debugging purposes I output the data in the packet, and it does indeed read 0x1D for that particular message. I'm attempting to get a dump of the instructions that are executed for that byte to see if anything odd is happening there. Specifically, I want to look at whether it's attempting to write 0x1D or 0x15 to memory. > 0x1D may be written to the socket, but are you sure that is > what is coming out of the other end of the pipe? Let's say > you slightly corrupt your memory (I haven't looked at the > code, so I don't know how you allocate memory and control > it), and this corruption is apparent only on this byte, > producing (since the program/rom is running through the same > sequence each > time) a reproducable error in the socket memory buffer only > on this byte. > > Assuming the socket recieve buffer is not corrupted, the > firmware buffer the final byte is added to may be. Again, I > haven't looked at the code or been able to get the firmware > to download, so you may be printing out all recieved bytes. > > This is why I hate straight C. > > ----- Original Message ----- > From: "David Edwards" <d.a...@du...> > To: <rcx...@li...> > Sent: Friday, October 18, 2002 7:22 PM > Subject: [Rcxemul-discussion] Strange things afoot > > > > I'm hot on the trail of the reason why the firmware won't > unlock. I've > > discovered that the last time I tried it, there was only > one byte in > > the entire firmware transferred wrongly. This put the > checksum off by > > 8: > > > > Expected > > 0xA000 77 79 1E 11 1E 88 1E 00 0D 42 1D 20 47 1E 6E 6A > > > > Observed > > 0xA000 77 79 1E 11 1E 88 1E 00 0D 42 15 20 47 1E 6E 6A > > > > Note that we have 1D in the expected firmware image, and 15 in the > > observed. I have no idea why! I've traced through the tons of debug > > information that I have and I'm still at a loss. 0x1D is definitely > > the value that gets transmitted by the firmware downloader, > but 0x15 > > is being written. > > > > I'm going to try again to see if it's the same byte that > gets written > > wrongly. If it is, I'm going to have to trace the receive > handler for > > that particular byte to see why it's not getting set correctly. > > > > > > > > ------------------------------------------------------- > > This sf.net email is sponsored by: > > Access Your PC Securely with GoToMyPC. Try Free Now > > https://www.gotomypc.com/s/OSND/DD > > _______________________________________________ > > Rcxemul-discussion mailing list > > Rcx...@li... > > https://lists.sourceforge.net/lists/listinfo/rcxemul-discussion > > > > ------------------------------------------------------- > This sf.net email is sponsored by: > Access Your PC Securely with GoToMyPC. Try Free Now https://www.gotomypc.com/s/OSND/DD _______________________________________________ Rcxemul-discussion mailing list Rcx...@li... https://lists.sourceforge.net/lists/listinfo/rcxemul-discussion |
|
From: David E. <d.a...@du...> - 2002-10-19 02:03:30
|
The byte in question does get set to 0x1D as it should. But at some point between then and the end of the download it is being set to 0x15. I'm attempting to narrow it down by outputting the value of the program counter whenever that value is changed. I should at least be able to see what function it is being altered in. > The error is repeatable. I tried again and exactly the same > byte was written incorrectly as 0x15. When the emulator > receives a packet, for debugging purposes I output the data > in the packet, and it does indeed read 0x1D for that > particular message. > > I'm attempting to get a dump of the instructions that are > executed for that byte to see if anything odd is happening > there. Specifically, I want to look at whether it's > attempting to write 0x1D or 0x15 to memory. > > > 0x1D may be written to the socket, but are you sure that is > > what is coming out of the other end of the pipe? Let's say > > you slightly corrupt your memory (I haven't looked at the > > code, so I don't know how you allocate memory and control > > it), and this corruption is apparent only on this byte, > > producing (since the program/rom is running through the same > > sequence each > > time) a reproducable error in the socket memory buffer only > > on this byte. > > > > Assuming the socket recieve buffer is not corrupted, the > > firmware buffer the final byte is added to may be. Again, I > > haven't looked at the code or been able to get the firmware > > to download, so you may be printing out all recieved bytes. > > > > This is why I hate straight C. > > > > ----- Original Message ----- > > From: "David Edwards" <d.a...@du...> > > To: <rcx...@li...> > > Sent: Friday, October 18, 2002 7:22 PM > > Subject: [Rcxemul-discussion] Strange things afoot > > > > > > > I'm hot on the trail of the reason why the firmware won't > > unlock. I've > > > discovered that the last time I tried it, there was only > > one byte in > > > the entire firmware transferred wrongly. This put the > > checksum off by > > > 8: > > > > > > Expected > > > 0xA000 77 79 1E 11 1E 88 1E 00 0D 42 1D 20 47 1E 6E 6A > > > > > > Observed > > > 0xA000 77 79 1E 11 1E 88 1E 00 0D 42 15 20 47 1E 6E 6A > > > > > > Note that we have 1D in the expected firmware image, and 15 in the > > > observed. I have no idea why! I've traced through the > tons of debug > > > information that I have and I'm still at a loss. 0x1D is > definitely > > > the value that gets transmitted by the firmware downloader, > > but 0x15 > > > is being written. > > > > > > I'm going to try again to see if it's the same byte that > > gets written > > > wrongly. If it is, I'm going to have to trace the receive > > handler for > > > that particular byte to see why it's not getting set correctly. > > > > > > > > > > > > ------------------------------------------------------- > > > This sf.net email is sponsored by: > > > Access Your PC Securely with GoToMyPC. Try Free Now > > > https://www.gotomypc.com/s/OSND/DD > > > _______________________________________________ > > > Rcxemul-discussion mailing list > > > Rcx...@li... > > > https://lists.sourceforge.net/lists/listinfo/rcxemul-discussion > > > > > > > > ------------------------------------------------------- > > This sf.net email is sponsored by: > > Access Your PC Securely with GoToMyPC. Try Free Now > https://www.gotomypc.com/s/OSND/DD > _______________________________________________ > Rcxemul-discussion mailing list > Rcx...@li... > https://lists.sourceforge.net/lists/listinfo/rcxemul-discussion > > > > ------------------------------------------------------- > This sf.net email is sponsored by: > Access Your PC Securely with GoToMyPC. Try Free Now https://www.gotomypc.com/s/OSND/DD _______________________________________________ Rcxemul-discussion mailing list Rcx...@li... https://lists.sourceforge.net/lists/listinfo/rcxemul-discussion |
|
From: David E. <d.a...@du...> - 2002-10-19 03:09:20
|
Finally figured it out! A bug in my bit operation instructions meant that instead of changing a bit in the byte at a specified memory address, it would read a word from this memory address and use that word as the address of the byte to alter. It just so happened that at that moment, 0xA00A was in the word at that memory address, so it cleared a bit in the byte at 0xA00A. Hence 0x1D became 0x15. The offending instruction was in a periodic update of the LCD. My next job is to work out if the firmware is being executed. If it is, I'll need to have a look at the lejos code to work out what should happen after it has been downloaded. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X