JP1 Remotes

I just got back my 6012 that I sent to OFA...they put a 1K EEPROM in it, and I did a 981 reset with it and tried to connect it with IR and I get the following message:

Bad checksum at address $0000. Expected $13 $EC, but found $EC $13.

I click OK, and I'm back at the IR main window. I try to change something, like change the CBL device code to 0477, and then try uploading to remote, and it blinks twice, then gives one long blink, and the code is reset back to 0476 (the default).

I've read something about modifying an RDF to get it to work, but I downloaded the 1K RDF from the Tools folder at the Yahoo! group and it still happens. Suggestions?

That symptom occurs when the checksum area specified by the RDF is either one byte longer or one byte shorter than the true checksum area (one more or less of the FF's near the end of the eeprom image inverts the checksum value). I would have thought we'd have that right by now, but apparently not.

I've read something about modifying an RDF to get it to work, but I downloaded the 1K RDF from the Tools folder at the Yahoo! group and it still happens. Suggestions?

If i've understood other posts correctly when downloading from the remote IR uses a sequence of bytes in the eeprom image to determine which RDF file to use. The RDF files are named such that the first 8 characters are this string. For the 2k and 1k versions this is the same, so make sure that in your rdf directory you only have the 1k rdf file in (e.g. 6_806_80 (URC-881x_801x_601x 1k).rdf), otherwise IR might be picking up the wrong one (?)

pgk wrote:otherwise IR might be picking up the wrong one (?)

If IR finds more than one matching RDF, it will prompt you to select one. Make sure to select the 1K version at that point.

Also, IR caches the RDF contents while running, so if you make changes to an RDF, make sure to shut down IR & restart it so you are sure it is using your changes.

If IR finds more than one matching RDF, it will prompt you to select one.

With IR 5.09 at least that isn't always true. e.g I had been using 2117 extender 2. So I created a copy of that changing the name and content slightly. Next I opened IR and download from my remote. No prompt was received, it just used the original one. However when I renamed the original and restarted IR it did then prompt for which one I wanted to use.

It looks like IR recalls the most recent RDF used and reuses that if the signatures match without checking if a "duplicate" exists. (Which will of course normally be what you want.)

IR only prompts for multiple RDFs when it has to change from one remote type to another. If you shut it down and restart it, it will re-cache the previous RDF, hence it does not prompt for you to choose. One way around that is to manually choose a different RDF, then download from your remote. This will force it to do a new search for all the RDFs for your remote.

I went to extreme measures and removed every RDF from the IR folder except for the 1K version. Same problem, only now the message is:

Bad checksum at address $0000. Expected $17 $E8, but found $F1 $0E.

Clicking OK...
There is a conflict at fixed data address $0023. Do you want to replace the existing data with the fixed data?

Clicking Yes...nothing.
Clicking No...nothing.

I don't know what to do.

Was this after another reset? Since the "wrong" checksum your first message differs to this one...

Yes. I just did a 981 reset and now it says it expected $CD $32, but found $32 CD.

ti83programmer wrote:Same problem, only now the message is:
Bad checksum at address $0000. Expected $17 $E8, but found $F1 $0E.

This is not the same problem as reading the wrong RDF. As John mentioned above, this is indicative of a wrong address in the RDF for the checksum calculation.

Re-do a 981 reset on the remote, and then try editing the RDF until you can download without the checksum error. Currently, the RDF section controlling this readsChange the $3FF value one address lower each time: $3FE, $3FD, etc. Usually it's only off by a few addresses, so if you don't get success after a dozen tries, then it's not going to fix it. In that case, you'll probably have to post the IR file (with no RDF active) for someone to look at.

ti83programmer wrote:There is a conflict at fixed data address $0023. Do you want to replace the existing data with the fixed data?

This is not a fatal error. IR is simply telling you that a byte in the EEPROM that is considered (by us) to be a constant value is not the correct value. You usually answer this Yes, but if it causes problems, you can answer No. Either way, IR will be able to upload & download properly.

I apologize for not figuring that out earlier. I changed it to $3FE and it worked. Thank you!