Just a footnote to mention that I actually did manage to retrieve the e2p contents without having to crack open my original ECU and BDM-read it.
At the start of this thread, I wanted to make a spare ECU so that I could learn and practice, but still have my original ECU to fall back upon should I mess things up. To clone the ECU though, I learnt you needed both the e2p and flash and whilst I could read out the flash over ODB2, I could never get the e2p contents without opening the ECU and using BDM to read it. I didn’t really want to open up my original ECU, so in the end I settled for making an immo-off ECU as described in the thread.
However, the e2p is
mirrored in the RAM as well and so you can indirectly get the contents of the e2p by reading out the RAM. I used a little RAM logger made from an Arduino and SparkFun CANBUS shield and read out RAM locations
0x7F8000 to
0x807FF0 using KWP2000 commands
0x2C (DynamicallyDefineLocalIdentifier) and
0x21 (ReadDataByLocalIdentifier). Just loop until you’ve read the whole range of addresses. Reading the RAM works both in the car and on the bench.
Once you’ve got the printout of the RAM and made it look nice and tidy in a hex file, you can open it in a hex editor and search for the VIN. If you don’t know the VIN, just look for the first few letters since they all start with that anyway. The VIN appears in a few places but if you see it repeated with a few bytes between instances then you are in the right region. This helps narrow down the general location of the RAM mirror.
Now have a look at this generic e2p screenshot and you’ll see it’s made up of blocks (01 03, 02 04, 03 04, 04 03 etc). Each of those is a block number and marks the start of a series of bytes that make up a block. The blocks are described in the FR in section EEP_CONF 5.150.0 EEPROM-Layout if you are curious.
If you look at the RAM dump, you’ll see the very same blocks
Using a hex editor, simply copy each block from the RAM dump file to a generic e2p file, overwriting the e2p contents with the RAM dump contents. If you see a block repeated in the e2p, that’s not an error. Some blocks have two physical copies for redundancy. Just work though the e2p file, making sure each block in the generic e2p hex file is overwritten with the same block number from the RAM dump file.
Copy block 01 03 from the RAM dump file
Paste block 01 03 into the generic e2p file
The e2p file itself is duplicated – the second half is a copy of the first half. So when you get halfway through, you can simply copy the first half (0x000 to 0x7FF) and paste it over the second half (0x800 to 0xFFF).
Now that you have an e2p file that’s a faithful representation of the e2p, you can check it using
Lar’s great tool 
If you BDM-write this new e2p file down to your spare eBay ECU, along with the flash you read out via ODB2, then you will have a working immo on clone of your ECU!
One thing to mention is that the first 64 bytes of the e2p file is not in fact in the RAM mirror and so can’t be read out and copied across. As far as I can work out, it’s just a date and a hardware/software number and doesn’t seem to interfere with the immobiliser. Certainly I now have my immobiliser switched back on in my spare ECU and my un-opened original tucked safely away
