I've been getting this message under certain conditions for a while. I mentioned it offhandedly in one of my other posts, but nobody else commented, so I wasn't sure if I was the only one seeing it or not.wnewell, in another thread, wrote:Download from remote no problem. But on upload, verify fail with data doesn't match or something like that, but everything appears to be ok when I download from remote and look at it.
Probably not, since I'm getting the same error message as you, but with a self-built cable.wnewell, in another thread, wrote:I'm wondering if the failed upload message is because of my cable.
I think it will if you enable the "Verify Writes" option under the "Interface" menu item.wnewell, in another thread, wrote:but I'm not sure if ir.exe verifies uploads either..
I'm becoming pretty convinced that it's a bug, as explained below.gfb107, in another thread, wrote:I don't know about the upload verify fail message. It may be real or it may be a bug.
That's wise advice, but in this case, I don't think he'll find any difference. The mismatch, in my case, has been internal to RMIR -- it appears to be corruption of an internal data array (more below).gfb107, in another thread, wrote:You could save before uploading, then save to a different file after downloading and compare the [Buffer] sections of the before/after files and see what if anything has changed
For the record, here's the exact error message that appears in the pop-up dialog:
Code: Select all
Upload verify failed: data read back doesn't match data written.
In fact, I was preparing a post about this very issue yesterday (most of which is now included below) when I encountered some odd, unpredictable behavior that made me hold off because I started thinking it might be a procedural error on my part.
Like 'wnewell', I'd found that the error doesn't seem to affect the operation of the remote. It's as if the error message itself was an error!
In other words, I've noticed that the failure message never seemed to really be meaningful because the remote control would always work as expected after such a failure message, as if the upload had succeeded perfectly well.But, I'd already (sporadically) spent 3 or 4 hours over the course of 2 or 3 days chasing this down. I had developed a reliable way to duplicate the problem, so I added some test code to dump some information to the log. In the part of the code where that failure message occurs, I added this code:
Code: Select all
//
// Dump the mismatched parts of flash RAM...
//
for ( int i = 0; i < data.length; ++i ) {
if (data[i] != readBack[i]) {
System.err.println( "Failure: " +
Integer.toHexString(i) + " " +
Integer.toHexString(data[i]) + " " +
Integer.toHexString(readBack[i]));
}
}
Here's what my test showed for the mismatched data:
Code: Select all
Failure: 400 148f 8f
Failure: 40e ffffffa8 a8
Failure: 40f ffffffa8 a8
Failure: 410 ffffffa8 a8
Failure: 411 ffffffa8 a8
Failure: 425 1450 50
As you can see, these mismatched bytes all seem to be caused by some sort of corruption of the high-order byte of the 16-bit value of the data that RMIR thinks it uploaded. This corruption seems to occur when I change one of the entries for "Setup Code" on the "General" tab before performing the upload, but there may be other cases which trigger the problem.
Armed with that knowledge, I tried to figure out exactly where the corruption was actually ocurring. I even tried learning the Java debugger well enough to "trap" it. But I failed. For some reason, I cannot seem to get the Java debugger to stop where/when I ask it to!
So, having pinned the problem down as much as I realistically could without a day-long Java tutorial, I was getting ready to officially ask for help from the "RM master".
Then I saw some odd behavior that made me think I might be doing something wrong. Then the post by 'wnewell' in the other thread essentially forced the issue.Greg, any ideas what's causing this corruption? Or any tips on running the Java debugger?
Here's the sequence of events with which I can predictably cause the problem:
- Run RMIR. (All my testing was with v1.96 on Linux.)
- Open this RMIR file: 'RS-15-135-with-Magnavox-device-upgrade.rmir'. It's got a device upgrade (taken from the forum) for a Magnavox ATSC tuner box (TB100MW9) and changed to use the RS 15-135 remote.
- Change a "Setup Code" on the "General" page. I was changing the "DVD" device from code "0636" (the default in a virgin RS 15-135 load) to "1010".
As near as I can tell, this (or something triggered by this action) is the point where the internal data array is corrupted. - Upload to the remote. You should then see the "Upload verify failed: data read back doesn't match data written." error message.
Even though my test case may be invalid, I think it may be useful for tracking down the source of the data corruption, which may be happening even in "valid" test case scenarios. I just haven't had time to pin that down.
I was really hoping to debug this a bit more before posting about it because I didn't want to essentially dump this in Greg's lap if I had a chance of figuring it out. But my inexperience with Java may have meant that posting for help was unavoidable anyway. So, I'm sorry to dump this one on you, Greg. I actually was making a "best effort" to figure this out on my own. If there's anything more I need to do to debug this (above what I was already planning), please let me know.
Bill
