NefMoto

Input command "ME7EEPROM.exe" --bootmode 95040 -w -p1 -b 9600 "Immo_off.bin"
Baudrate 10400, 19200 or 57600 also don't work.

I have verified my bench setup works using VCDS, so that is not the issue.

ME7_EEPROM v1.40
COM: 1, Baud Rate: 9600
Memory type: 95040, size: 512
Opening COM1 ... OK
Starting Boot_mode ... uC ID response 0xFD. Unknown ID. (error=0x40201)
Closing COM1.

Now what's very odd to me is that using EXACTLY the same command gives me different uC ID responses. EG: 0xF9, 0xF5, 0xFD, 0xD6. Now when changing baud-rate i get different responses aswell (19200 - 0xCC, 0xC8 etc.) What is happening, and why does this not want to work? It seems extremely straight forward yet i'm having a hard time.

It seems like some sort of ID check is preventing me from programming this chip, is there a  way to get rid of this? As i'm certain i've got the proper hardware.

032HA ME7.5 ECU and on the bottom is the 95040 chip.

If someone could confirm what actually is my issue, and if it's Identification related.

If so, is there still a repo around of the me7eeprom code? I'd have a look with my rusty programming experience to see if i can get anywhere and perhaps change or fake this check.

Or another (hopefully easier) solution is also welcome

How you put ECU in boot mode? What pins get ignition, what pins have constant power

https://www.amazon.co.uk/MyCor-Media-ME7-Direct-Control-Devices-KWP2000/dp/B07CLMKXZT

I have purchased one of these, as fukenbroken suggested. So i don't believe this to be at fault. It also read fine using OBD mode, but not through bootmode. The application does seem to imply that is has gone in bootmode aswell.

I get that sometimes, but I can always contribute it to me being too quick.  A retry gets it in.

Still you didn't answer  ::)

I mean, vcds works. I think i can be quite sure this adapter works as intended.

So 12v to 3, 21, 61. Ground to 1, 2. And k line on 43.

I grounded pin 24 on the pcb as one should to put it into bootmode.

Will have a go again tomorrow.. thanks for suggesting.

How much you hold ground to 24 pin

I try a few times untill i get it, probably like 3-5 seconds.

I constantly get shit for calling out the fucktards who refuse to release source. This is why. Abandonware in the name of "my code is special" is cancer.

This, sad because it seems to be an amazing tool. Seems some ID issue is messing with me for no apparant reason. I sadly don't have the knowledge to "fix" a compiled exe.

I read somewhere that >2004 ECU's could have issues. This spare just so happens to be a 2005 ECU.

Desoldering the 95040 is probably my best bet to make this spare worthwhile...

Loud and clear, I hear you nyet!

I have actually fully re-written this tool in C for eeprom read/writing/check-summing and verification.
It is now much more reliable and stable (at least for me) than it ever was before as I use high resolution timers for delays.

Plus I've implemented some additional useful features like ;

> Eeprom checksum calculations
> Verification of eeprom writing by reading back and comparing the differences.
> Automatically detecting the eeprom pins and sizes - this works by parsing that information directly out of the accompanying firmware so its fully automatic in use, you don't really need to know anything to use it.
> It supports differential analysis too if you load in 2 different eeprom files to see what's changed.
> Finally it also can parse out of the firmware the page table too.

I use the exact same mechanism as the original tool in that I upload bootstrap loader so you need to start it in "boot mode", then I upload a small C167/ST10 eeprom driver in memory and send commands to read/write blocks between the pc and ecu.
I'll see if I can clean this lot up and put it on github as soon as I get some free time...

It would be pretty easy to also implement the virginizing of eeprom too but its going to be firmware specific (I already support it for my targets but didn't look into this for any other cars like VAG)

This sounds amazing, looking forward to this.

-Ground 1 and 2
-12V to pin 62 on ECU
-Ground from ECU PCB to pin 24 on 800BB
-Put 12V to pin 3 on ECU
-Wait 10 sec
-Remove ground from pin 24
-Read eeprom with boot mode

Will this work with CH340 cables / general uart or you made use of ftdi drivers/dll's requiring ftdi based cables? Sounds good regardless, well done.

Currently it only support bogo standard COMx ports, not FDTI directly.

I do however "Prioritize" named COM devices so they are automatically discovered and connected to with first priority, .e.g. "USB Serial Port". This is behavior is adjustible in the configuration file.  This means if you unplug and plug in say a 1260 cable it will automatically detect it and just use it unless you specifically want to override this.

If you wish to use anything more complicated than a $2 USB-Serial Uart adapter connected to a K-Line ic L9637 transceiver ($2) then you can always just get around this with software. For instance the later FDTI drivers normally have an option in the advanced tab on the device driver to use "Virtual Com Port" and then they become accessible just like normal USB-Serial adapters again via comX numbering.

Is this going to check st10 EPROMs?! :o

Found another situation where the program doesn't work sadly.

- Passat AWT 4B0906018DH ECU

Think the problem might be the fact that this is a CPU with 6.02 bootrom. Always fails on sending EEPROM driver.