EEPROM RL86 (93C86)

[pegasollanera]

Hello, I have a problem with an eeprom, I have to clone it for a motorcycle unit, I read it and I copy it in another eeprom but for some reason it does not work, I think it has some encryption in the file or some password, I'm going to publish the file in case someone can help me.
Thanks.

[pegasollanera]

the eeprom I read it with 4 different programmers and the new ones I wrote also with those 4 programmers, but it does the same, when the salary on the board I read them with the interface of that motorcycle and the altered or corrupted data come out, someone could tell me if the file is protected or encrypted ?.
also say that I have a correct file, but it is read from another board with the interface and it does not look like anything, it has a larger extension and it is in a different format (.bin), it is format (.gsd), I try to load it with the interface but does not write the eeprom.

[SMdude]

The second file looks fine to me.
Are you programming in circuit?
Are you holding the mcu in reset while you are trying to write?
Otherwise, try on digital kaos forum under dashboard section.

[pegasollanera]

the second file is to load with the program and interface of yoshimura, the first one is read desoldering the eeprom and placing it in the programmer, if I pay the eeprom of the first file to the plate if it lets me write with the program yoshimura and the interface but if I pay the cloned one, I need to be able to clone it to repair another one.

[SMdude]

Have you tried reading the eeprom as 16 bit? This sometimes helps.
So are you able to copy the original eeprom and fit the copied eeprom back to the dash that the original came from? Does this work?

Does the good eeprom work in the dash you are repairing?

Are you sure you have the correct eeprom part number?

[pegasollanera]

the eeprom puts RL86, I read it in all possible ways and with 4 different programmers, in 8 bits and in 16 bits, I wrote it with the reading of 8 bits in 8 bits, 8 bits in 16 bits, 16 bits in 16 bits, 16 bits in 8 bits, and it does not work in any way, I also know that the person who made the modification on that board protects the data, because the microprocessor was also password protected, the eeprom that the salary is well on my board and if it works, the problem I think is because it is written with some encryption or protection, and the eeprom I'm sure it is an RL86 that is equivalent to a ROHM 93C86

[SMdude]

At the end of the day, the eeprom is just a binary file.
If that file is encrypted on the eeprom and you read the encrypted file and write the encrypted file, the file is the same???

I could not see anything fancy in the datasheet for 93c86 for encryption.
Perhaps the rl86 has some other data areas that the 93c86 doesn't?

Try at the link below. I know nothing compared to the guys on digital kaos...
http://www.digital-kaos.co.uk/forums/forumdisplay.php/174-DashBoard

[pegasollanera]

I know digital kaos and I'm a member but you direct me to a forum for dashboard and this is an engine unit (ecu)

[SMdude]

I only found one thread on there that mentions yoshimura.
Try the ecu forum..
http://www.digital-kaos.co.uk/forums/forumdisplay.php/175-ECU

[pegasollanera]

How can I keep in mcu on restart? is a renesas m32r m32196f8, what pin do I have to put to ground? the reset?

[SMdude]

Yes, the reset pin. This should put the IO pins into high impedance state and allow you to read/write the eeprom in circuit.
But make sure you can do this in your ecu, check for pull up/down resistors on the reset pin. Make sure the pull up/down resistors are not a 0r link. I take no responsibility for any smoke you may let out!

Reading/writing with the eeprom out of the circuit is the safest way and should work, but if you are experimenting/having trouble as you are, it would be advantageous to leave the eeprom in cct.

[pegasollanera]

I do not get it, nobody knows how to decipher the first file I uploaded to the forum?

[Fraser]

As has been stated, an EEPROM of the type you describe is not equipped with read protection bits (it would be pretty useless if it was!) or encryption. It is 'just' a pile of memory cell locations that are filled with 1's and 0's. An EXACT clone of it should behave the same as the original.

I say EXACT clone as I have met EEPROMS that were not the standard 'off the shelf' part and had no easily obtainable equivalent. I also met one equipment that did some weird stuff with memory addresses and the start of the code had to be at a specific memory location and not at 0000H as I had programmed. I made the mistake of reading the IC and just burning the program into another EEPROM with a 0000H base address. I actually needed to CLONE the chip exactly.

This may not help you in your case but I thought I would share my experience with awkward EEPROM copying.

[pegasollanera]

I have made several clones of that eeprom, I compare them and they tell me they are fine, although once I pay the eeprom to the board and I read with the interface they are not the same, in the end you got to clone your eeprom?, if you got it, I can you say how?

[SMdude]

Does you eeprom reader/writer have the option to read the eeprom as "binary"?
I have sometimes found that binary gives me good results and other formats not so good.

Failing that you might have to reverse engineer it using a logic analyser, watch the address requests and see the output data.
Make sure the address commands stay within your expected address space and that the data out for an address matches what you have read with the eeprom programmer.

Sorry I can't be of more help, but that is what I would do.

[Hawke]

Just curious has the prom you are trying to read have protection fuses programmed into it. I'm guessing if its a genuine Yoshimira prom it has read protection programmed into it. You can clone them but they wont work due to the protection. A high level reader writer can get around fuses I use a ChipLab 32 now discontinued and it was renamed as a LabWriter by Data IO. Also there are some differences in EEPROM's such as the Byte order. Sometimes I found Intel byte order would clone onto Motorola byte order but fail to work because I forgot to change the destination byte order. I'm guessing you know all this but mention it because I ran into similar problems when I first started cloning and modifying performance chips. It was many moons ago. Cheers 

[pegasollanera]

hello, it is not original yoshimura, it is a clone that another person made, I believe that it is who protected the eeprom since the mcu also protected it, although I managed to read it and remove the key.

[amyk]

93C86 has no security features. It has a write protect bit but that's only to prevent accidental writing.

[pegasollanera]

aki there is something, and I still believe that the file is encrypted

[pegasollanera]

the second file that I uploaded to the forum, I try to load it in the eeprom with the software EM PRO of yoshimura, it starts writing and it reaches 100% but it does not write anything and it gives me an error of cheksum.

[SMdude]

Ok, I have had a closer look at things..

The file names .gsd contains a morotola S record.
This S record is what you have read from your eeprom. The S record you have read from the eeprom is different to the S record in the .gsd file, but it looks like it has read correctly as the first line almost matches the data in the .gsd file.

So, you must not be holding your tongue correctly when you are programming the new IC.

When you read the data back from the new IC, does it match the data you read from the original?

If you really wanted to you could take the contents of the read eeprom file and edit the .gsd file with the new data, but this would be quite painful to manually edit as you would need to do it one line at a time. You would need to write a small program or script.

The first line of data in the gsd file is:

FF80807F00007F7F00007F0D0C0C0B0AB7  (the B7 must be the checksum for the line)

And the first line in the eprom when viewed as HEX is:

FF80807F00007F7F00007F0D9D398480 (insert line checksum here)

So, I don't know what to suggest...

[amyk]

D0C0C0B0A = 110100001100000011000000101100001010
D9D398480 = 110110011101001110011000010010000000

Looks too far apart to be timing-related, but there's always the possibility that the EEPROM is flaky --- you could try a slower read speed.

[SMdude]

Actually, the checksum is missing at the end of the file...

I am sure that the file has read correctly going by the contents and the general formatting of the file. The FF's and 80's are in the right place and there are too many other similarities. The only byte missing is the last checksum byte.

Look at the gsd file in text mode and look at the eeprom file in HEX
In the gsd you have the destination address, 16 bytes data, 1 byte checksum.

If you chop out the 16 bytes of data you end up with a file very similar(text hex) to the eeprom file.

The attached file is the data contents of the gsd file, but as text, it would need to be converted to hex to actually work.

[pegasollanera]

hello, I've been fighting with it all day, compare the 2 files with 010 editor and I could see that the gsd file is almost the same as the eeprom file by inverting the bits, but the file of the eeprom has 11 first different lines, also check that if I read the eeprom in 8bits a very different file comes out, I'll upload it to them so they can see it.
Thank you very much for your advice.

[pegasollanera]

attached photos

[pegasollanera]

hello, I've seen that when I clone the eeprom as 16bits it remains the same, but if once I read the eeproms clone the original 8bits are different data than the new one, in the original they do not look anything like those read in 16bits, while the new eeprom keeps the same data but inverted.

[amyk]

Are these being read in or out of circuit?

At address A0 in your second image, it looks like the EEPROM suddenly jumped back to the start...

I would set your reader to the slowest speed and try again.

[up8051]

RL86 it is BR93L86 EEPROM from ROHM Semiconductor.
It always work as 16-bit.
What memory you use as replacment (type and manufacturer)?

Regards,
up8051

[pegasollanera]

hello, it's read off-board, the second image is the file that has the emos of yoshimura to load interface, and I do not know how to change the speed of the programmer, I already knew that rl86 is from rohm, I'm using st 93c86wp and also st 93c86 6.

[pegasollanera]

hello, I have seen in a software that I have how to encrypt and decrypt peugeot and citroen files in eeprom, so I see that if the file of the eeprom that I uploaded to the forum can be encrypted, I attach photo.