NefMoto

Well, I've finally got my cq-4X programmer and the 3M soic8 clip adapter.

I've got a few more questions, after doing some dumps and etc... it seems that i cant write to the chip while its on the board, I've tried with an external power supply ( 9V 200MA as the programmer calls for ) and i get the same failure on verify each time.

is there a known issue with trying to program it while its still soldered on?

For the second question, How are the check-sums calculated for the eeprom? the same as the Flash? So would loading it into a program with the ME7.5 Check-sum plugin correct it?

Both bin files are posted below, If someone could check my work, that'd be awesome!

The last one or two bytes of each 16 byte page is the checksum, and it is literally just the sum of the bytes in the page. You should just be able to manually correct them.

Awesome to hear, I'll need to check the numbers again, but by the sounds of it's right.

Thanks tony,

I've been thinking more about my flashing issues today, There was a mention on a previous thread about powering the ECU and grounding the ECU's clock gen.

Can anyone think of a way to do that? or expand on the subject? Each way and method that i think involves shorting out both the ecu and the programmers clock, de-soldering, or cutting traces to sever connections.

The Golden Grail of this whole ordeal would be to flash without desoldering the chip, hell, thats the whole reason i got the clip! :D

Sorry to bother you a little more, my somewhat limited and feared exposure to hex, is there a simpler way to calc the sum of the hex values?

I've converted them to decimal, added, then tried to convert back to hex and all I'm getting back is simply garbage.

Try downloading a simple HEX-editor (one suggested below), open the file in question, mark the area you want to calculate the sum on and go to to the "Analysis" function and click "Checksums" to choose the type of checksum you want to calculate .

http://mh-nexus.de/en/hxd/

It's a little more complicated in that. I am still working out the specifics, so please correct me if someone knows better..

Not all regions have checksums. Page 0 (0x00 - 0x0F)?

The checksums for pages 1 to 14 appear to calculate as follows..

FFFF - ((Chksum-16 of first 14 bytes)+(page number-1)) then swap the Hi and Lo byte

So for my page 1 (0x10-0x1F)
05 01 02 00 1E CF 01 00 03 00 5A 8E 00 D2 4C FD
Checksum16 of [05 01 02 00 1E CF 01 00 03 00 5A 8E 00 D2] = 02B3

FFFF - ((02B3) + (1-1)) = FD4C The checksum is 4C FD

For my page 2 the data is repeated so the checksum is

FFFF - ((02B3) + (2-1)) = FD4B The checksum is 4B FD

This covers the first portion of the EEPROM but I haven't looked further to see which regions are covered. With a good dump it should be simple to work it out.

-C

I have added a summary in http://www.nefariousmotorsports.com/forum/index.php?topic=362.0

Nice work. May I ask from which part of the object code you got this info from?

I'm not sure the page info table is constant across car models & ecm versions.

I've played around a bit and made a small perl script for verification. It doesn't use the weird method the ME7 uses, it simply compares against an array with offsets from (0xFFFF-<sum>). Only the first 16 pages are checked. It also prints soft coding and speed governor offset.

Using that program, would calculating the checksums be CRC-16?

On this line:
05 01 02 00 CB 86 00 00 00 00 69 C1 00 A5

Checksum - 16 gives me: 0328
While CRC-16 gives: E74C

CRC is the only one that "looks" correct.

Edit: it cant be correct, when I've highlighted and checked the lines that are non edited, i get some strange values.

I think the info you need is already in the previous posts above.

i cant see that being correct, unless there is a flaw in my math.

Using a known line:
32 39 4D 37 32 4D 30 33 34 31 39 39 56 01 F4 FC
The Checksum would be F4 FC, Keeping that in mind.

the checksum - 16 for the first 14 lines is: 02FF

So plugging that into your equation
FFFF - ((02FF) + (1-1)) = FD00
Flipping it as you said, 00 FD.

You need to locate e.g. the following function in your image, then you know the address of
the eeprom_info_table and can check wether there exist different versions:
; INPUT:
;   R12 = ptrBuffer
;   R13 = pageNumber (0..31)
; OUTPUT:
;   R4 = 0 (checksum is OK), != 0 (checksum is wrong)
verify_eeprom_checksum_from_buffer:
        MOV     [-R0], R9
        MOV     R4, R13                 ; Get pageNumber
        SHL     R4, #1
        MOV     R5, [R4+#eeprom_info_table]   ; val = eeprom_info_table[pageNumber]
        AND     R5, #0040h
        SHR     R5, #6                  ; cksumBit = (val & 40) >> 6
        MOV     R15, R13                ; Get pageNumber
        SUB     R15, R5                 ; baseCksum = pageNumber - cksumBit
        MOV     R4, #14
        MOV     R14, R4                 ; len = 14
        MOV     R5, R12                 ; Get ptrBuffer
        ADD     R5, R4                  ; ptrLast = ptrBuffer + len
        MOV     R9, [R5]                ; checksum = *ptrLast (old checksum)
        JMPR    cc_UC, L_enter_loop
L_loop:
        SUB     R14, #1                 ; len--
        MOV     R4, R14                 ; Get len
        MOV     R2, R12                 ; Get ptrBuffer
        ADD     R2, R4
        MOVB    RL4, [R2]               ; data = *ptrBuffer + len
        MOVBZ   R4, RL4
        ADD     R9, R4                  ; checksum += data
L_enter_loop:
        CMP     R14, #0
        JMPR    cc_SGT, L_loop          ; (len > 0) ?
        MOV     R4, R9
        ADD     R4, R15                 ; Return checksum + baseCksum
        MOV     R9, [R0+]
        RETS

Hey man,

I'm just posting to say sorry... the calculator i was using was giving me the wrong data..

You're 100% correct with it, and I'm going to correct my bins and reburn it.

thank you very much!

Were you able to get the file to write?   Try holding the write protect high.   ;)

Alright, I'll give manually holding it high a shot when i play with it a little more.

Thanks for the heads up Dreh. :)

This is all to weird, plugged it in, Program was on the wrong chip, error'd, changed its mode to 95040, Read/dumped the chip, it was junk, Programmed it with the correct bin and it programed without anything weird.

Is erasing the chip or anything needed prior? or was this ( Somewhat dumb ) move a stroke of luck?

Generally if you aren't getting a good read you shouldn't try writing to it. Did you read it to verify your write was successful?

Quite a few times now, and each time its been 100% correct.

I feel as though the error of having the programmer on 27C256 while trying to read the 95040 caused some corruption.

i can continue to check, But its checked out Four times now on two separate occasions.

I have seen cases of corrupting the data on eproms when trying to read them using the wrong chip type.