URC-6131 data read differs from data written error

[kshoemaker]

Hope this post landed in the right forum.

I've got 4 recently modified URC-6131 remotes and 3 of them are getting the "data read differs from data written" error on the upload operation. I can download fine, just not upload.

I'm using the BlueDo cable I've had for years. It passes all the tests and uploads to / downloads from 4 different URC-7800 remotes, 1 of the URC-6131s and a Kameleon, so I'm pretty sure the cable is fine. I've tried re-soldering the chips on the 6131s and fresh batteries but I still can't upload to the remote.

Any suggestions are greatly appreciated.

Thanks.

[The Robman]

I get that message occassionally when I'm testing remotes that I've just modified and the fix is to re-solder the 6-pin connector. All you should need to have to do is apply the soldering iron to the solder on each pin, one at a time, to re-heat it. Try to make sure that the iron is touching both the pin and the pad.

[kshoemaker]

I resoldered the connections and I think they are all good.

After a reset, I start with a new file in IR. I define 1 device button and upload successfully. When I download, I get:

Bad Checksum at address $0000. Expected $0F $F0, but found $D4 $C1 (The found values vary).

Followed by:

Protocol list not found after device list.

The downloaded results show the 1 device I defined, but the Device Type for the VCR button is set to <ERROR> with a device code of 1792.

Thanks.

[The Robman]

After a reset, I start with a new file in IR. I define 1 device button and upload successfully. When I download, I get:

Bad Checksum at address $0000. Expected $0F $F0, but found $D4 $C1.

First things first, after you do the 981 reset, you should download from the remote. Does the download work, any checksum errors?

Then try re-loading without changing anything to see if that works.

Have you tried doing the upload/download both WITH and WITHOUT batteries in the remote? Are you using a laptop or a desktop computer? If your JP1 cable is old, it may be an old design that uses a regular diode and 10k resistors. The current design calls for 1k resistors and a Shottky diode. If you are using a laptop, the new design is especially important.

[kshoemaker]

After the reset I can download fine and the remote blinks twice. The upload seems to work but the remote only blinks once. The next download throws the checksum error. The results are the same with and without batteries, minus the blinking lights.

I'm thinking it might be the cable as it is several years old. I bought it so I can't say what its got inside. Its still wierd that it works on 6 remotes, including one 6131, but fails on 3 other 6131s all on the same laptop.

Thanks for the quick reply as usual.

[The Robman]

Now that you've confirmed that you're using a laptop, and we already know your cable is old, I'd strongly recommend that you get a new one.

If you open up the DB25 end of the cable, is the diode a small reddish color with a black band, or is it a slightly larger and black with a silver band. If it's the latter, it's a Shottky, if it's the former it's a regular signal diode.

Next, look at the 2 resistors, if the 1st 3 bands are brown, black, red that means you have the 1k resistors (which is good), but if the colors are brown, black, orange it means you have the 1k resistors.

If you have some other combination of colored bands, you can use this color chart to figure out the value of the resistors.

[kshoemaker]

I've got the reddish w/black diode and the brown, black, orange resistors.

I've been looking into the new cable anyway and like the USB option. Other than interface, are there any technical pros/cons between the USB and the ultra parallel?

[The Robman]

That confirms that you have one of the old design, which never did work very well with laptops. Given that it partially works, I expect that you'll be able to a regular $14 Simple interface cable. I've never used any of the other cables so i can't comment on the differences.

[kshoemaker]

Tried the 1k resistors (no Schottky yet) and got the same results. Downloads OK but "data differs" on upload. Subsequent downloads fail w/"checksum" errors until I 981.

The new cable works completely on the laptop w/my 7800s and a 6131 but flakes out w/3 other 6131s. I moved over to a Dell desktop and get the exact same thing. I don't get it.

I'm still worried that my remote mods might be bad but I guess I can't be sure until I replace the diode or get a new cable.

[kshoemaker]

The units that fail have ISSI 928 16-2G on the EEPROM. The markings look like 805AD 24U16 LMB on the one that works. I can barely make out the print so I may be off by a character or 2.

They all came in the same order of 10 from Jameco. Only 1 had the latter markings and its just dumb luck my buddy happened to install it.

I don't know beans about the chips. Any idea if they're even the right item?

[The Robman]

I think we've found the problem, I don't know what those chips are but they don't sound like EEPROMs, at least, not the sort that we use.

A good EEPROM will have a number somewhat like 24C16, so the 24U16 chips are good.

I just checked an old email I got from Tom at Filebug and he was sent some of that exact same chip once and they didn't work for him either. So, you need to call Jameco and tell them that they sent you the wrong part and ask what they will do to rectify it.

[Bob_Collins]

I just ordered and received this same WRONG part, and discovered it after trying it and having it give the same symptoms. I sent an email to JameCo asking them to verify and send me the correct parts. I just wondered what happened with your order and how they handled it.

[The Robman]

So far, I've got good EEPROMs each time, though they have sent me two different brands. The last order I placed was for 300 chips, so I'm set for a while.

[kshoemaker]

I phoned them and explained the problem and they shipped me replacements the same day. Since my order was very small I didn't even need to return the bad parts.

The new items are from a different manufacturer. I haven't installed them yet (I'm actually waiting for my friend to do it since I lack sufficient soldering skills), but I will report on the success/failure as soon as I find out.

[Tommy Tyler]

I have a hunch your problem is not the interface, but I could be wrong. If you continue to have doubts as to whether the EEPROM is working properly after installing known correct EEPROM's and upgrading your interface (why don't you just get your buddy to replace the 10K resistors with 1K), here is some info that may be of help.

There are two aspects of uploading and downloading an EEPROM. The first is simply the physical process of reading and writing from/to the EEPROM, and the second concerns the actual content of the data. Even if the physical process proceeds flawlessly, The remote uP and the IR program are both demanding of certain content and format of the data (signatures, checksums, etc.) or they will complain in various ways (blinking LED's and error messages). Remote LED blinks are not a reliable way to judge the performance of an EEPROM. For example, a single, long blink by the remote following upload means the uP made some tests of the content immediately after it woke up from release of its reset signal, and it didn't like what it saw (usually the checksum). It doesn't necessarily mean the EEPROM didn't faithfully save the data exactly as it received it.

I suggest you concentrate instead on the little simulated LED in the lower left corner of the IR display. If that indicator blinks twice following an upload/download it is a pretty good indication the EEPROM is alive and well, regardless of LED blinks and error messages. Here's why.

Remember that the uP is asleep during upload/download, and has nothing to do with the process. To start an upload, IR first sends an address byte. The EEPROM has to receive that, compare it to its own address, and send back an ACK signal to show that it is ready to receive data. Then the EEPROM has to send ACKnowledgements of each and every other data byte the PC sends. Only if all that goes off without a hitch does IR blink it's indicator. To start a download the same address confirmation occurs, then the EEPROM has to send a byte of data each time the PC requests it. Again, no double blink from IR if anything goes wrong.

So you can see, the process is too complicated for an EEPROM that is defective, or installed wrong, or has intermittent solder joints, to fool IR into giving its "thumbs up" double blink.

But, you say, what if the EEPROM can send and receive OK, but can't read or write to/from its memory worth a damn? Highly unlikely, but a valid question. To resolve that question you should simply compare the data in an upload file with a subsequent downloaded file, and forget all about those error messages. Thank heavens IR will usually upload and download whatever it is given, even if it doesn't like it, by virtue of all the overrides it has.

To compare two 2K binary files, bit for bit, can be a bit daunting. If you give them different names you can use the old DOS FileCompare instruction. But let me point out that you can actually upload and download a giberish file that you create in Notepad or any other text editor, as long as it meets a few minimum requirements. Your file should consist of one or more lines of 16 pairs of hexadecimal characters, with each pair separated by one space. You do not need line numbers or colons, as you see in real IR text files. Try the following: Create a text file of 16 "aa's" that looks like aa aa aa aa aa aa . . . aa. Give it a name and save it. Open IR, click on the Raw Data tab so you can keep an eye on the data, and load your file. Disregard all of IR's complaining about signatures, file size, etc. Just override all that and upload the file. If IR double blinks, you're halfway there. Now clear the data buffer to all "F's" with Advanced>Purge Memory, and then download. If you get back the same thing you uploaded, quit worrying about the EEPROM. You can expand your text file to 128 lines if you want. Whatever satisfies you that the EEPROM is doing it's job.

You'll have to do a 981 factory reset to bring the remote back to reality.