Couldnt really find a section for this..

[88GreenVN]

Can you spot the 5-6-7 progression there?
It is checksummed too.

LOL - Nope. not yet.

If I change 1 of the 625 default settings it changes the D9 to a 59 - which no longer adds up with the check sum (D9 26)

[festy]

Your previous 59 example still checked out...

Code: Select all

+1 = 01 01 59 A6

[88GreenVN]

Your previous 59 example still checked out...

Code: Select all

+1 = 01 01 59 A6

Yes it does - but if I change the distance calibration by +1 it changes the D9 to 59 but the 26 stays the same.

81 01 59 26

This fails the add test for the second pair of bytes... and what happens if I change the tank calibration... back to shed I go.

[jxx]

great work guys interesting read.

hope this hasn't been been brought up and i missed it reading through, regarding the 8051 processor as mentioned a lot earlier has anyone tried desoldering it and reading the code out of it? just waiting for my programmer to show up and was going to attempt it.
My concern is that the rom and eprom have been locked.... can anyone confirm this?
From the 80C51BH pdf that i've read it may have been done.

ROM and EPROM Lock System
The program lock system, when programmed, protects
the onboard program against software piracy.
The 80C51BH has a one level program lock system
and a 64-byte encryption table. If program protection
is desired, the user submits the encryption table with
their code and both the lock bit and encryption array
are programmed by the factory. The encryption array
is not available without the lock bit. For the lock bit
to be programmed, the user must submit an encryption
table.

Encryption Array
Within the EPROM array are 64 bytes of Encryption
Array that are initially unprogrammed (all 1's). Every
time that a byte is addressed during a verify, 6 address
lines are used to select a byte of the Encryption
Array. This byte is then exclusive-NOR'ed
(XNOR) with the code byte, creating an Encryption
Verify byte. The algorithm, with the array in the unprogrammed
state (all 1's), will return the code in its
original, unmodified form. For programming the Encryption
Array, refer to Table 4 (Programming the
EPROM).
When using the encryption array, one important factor
needs to be considered. lf a code byte has the
value 0FFH, verifying the byte will produce the encryption
byte value. lf a large block (l64 bytes) of
code is left unprogrammed, a verification routine will
display the contents of the encryption array. For this
reason all unused code bytes should be programmed
with some value other than 0FFH, and not
all of them the same value. This will ensure maximum
program protection.

[festy]

I haven't got a cluster in front of me to check the part number - but yes, it has been discussed and from memory that NEC mcu used doesn't have the ROM lock capability, and it has no eeprom to lock anyway.

I was going to dump it via the code verification method outlined in the AN (or somewhere, can't remember where I found it) using a pic to handle the A/D lines - but there's no need, from what I've seen from the trip computer function posts the last couple of bytes will be deciphered easily (I've just been working on other projects so haven't got back to it yet).

If you're going to dump the ROM, post it up here. It'd be interesting to see. What programmer have you found that can read these mcus?

[jxx]

so they used a couple of different mcu's?
The cluster i have has a philips, intel PCF 80c51BH-3, i think it's from a VP, swapped the original board over to retain the odo reading years ago due to bleeding lcd's into another cluster which has the press remote illuminated when in rev on a s1 vn, anyone else able to confirm what mcu is in their cluster and what vehicle it's out of?
Just about any programmer can handle them, MCS 51 mcu, the willem will with an adapter.
Will post the rom image if/when i get it out.

[festy]

yeah sorry, i was thinking of a different cluster with the NEC mcu.
I get the impression from that datasheet that the P suffix mcus must be encrypted?

[jxx]

that's what i thought when i read the pdf, there is another pdf around with more info about the letters on the chip and contains more info on the lock but i can't seem to find it, most pdf's i can find now barely mention the lock, being vdo i don't like those chances of it being unencrypted.

[88GreenVN]

A Blue PCB trip computer = VQ or VN

Red = VP

[jxx]

seem to have a managed to get a weirdly corrupted nvram image, always thought it was an issue with the lcd screen since i swapped parts over.
managed to fix the image and atleast get a realistic odo reading on the display now. anyone able to make sense of why it still works and doesn't just display 555555 or are there characters it can display that aren't normally counted through and it passed the checksum?

Code: Select all

E8 01 CA A8 00 FF 20 DF F7 08 EC 13 91 6E 0D 0A
 F5 F7 08 EC 13 91 6E 0D 0A F5 F7 08 EC 13 91 6E
 0D 0A F5

using x2444 it doesn't display the the last 6 digits but reads/writes them

Wrote a repaired proper length file and the display showed the numbers it was programmed for, re-wrote the corrupt image and back to the odd display again.
The lcd behind the bleed is a 3 missing the lower right segment.



and test mode to show the lcd is fine