Hi All,
My first post(s) here, so please be patient with me. Also please excuse my english as it's not my native language.

I have Freelander 2 with an EDC16CP39 ecu. The engine is a 2.2 HDI from Peugeot in joint venture with LR and Ford.
The ECU is complying with all rules from ISO14229 and ISO15765 regarding CAN bus implementations.

The way of accessing the ECU, from Land Rover point of view is as follows:
- switch to programming mode,
- authorize yourself by the help of seed/key pair,
- download a secondary bootloader in RAM,
- run a routine from SBL and give full access to this SBL,
- erase desired section
- download the data or exe file to the ECU in the desired section,
- leave programming session.

This thing works with all ECUs on the car.
With the help of my own built interface hardware and software, I can modify and flash any firmware in any ECU on the car.

The problem comes when handling this engine ECU. I can download/flash the original files and all works OK. Works perfectly every time.
But when I am trying to modify any single bit inside the firmware, no matter that it's on the DATA/maps section or on the EXE section, at the end of the flash, the SBL throws an error and the memory will contain only a partial portion of the downloaded data.

I've seen at the end of each block of data a portion of variable length 20-130 bytes which contains strange info. It seems like a hash information or something. For example, the structure of a block will be: relevant data/exe info, the rest filled with 0xFF, and those 20-130 bytes at the end.
I've loaded the SBL into a disassembler for MPC5xx processors and I've seen that the SBL is accessing different zones in memory that normally aren't available to be read/write from SBL.

Questions are (again, we are talking here about an EDC16CP39 ecu, Bosch code: 0 281 013 202):
- is there any way of making a full dump of the memory, for example from 0x000000 to 0x800000? I've saw that the regular chiptuning software will download/upload only the ECU's data section from 0x180000 to 0x200000.
- is there any CRC algorithm, other than the one implemented in the original VBF files, involved in securing the download phase?
- if the above is true, I am right on those last 20-130 bytes at the end of each block to be the hash/key/crc?

Thank you all for your patience and help!

BDM will do a full read of the flash...
the portion you are refering to is the checksum area if I am not mistaken

I was hoping that I can read it without opening it... Oh well that's it.
Anyway, I was leaving that option as a last resort and if I'll open it, as I don't have a BDM interface built (yet), it will be easier to desolder the memory chip and read it through standard parallel method.
But I have the impression that this ECU has an MPC564 controller which has 512K of internal flash. Is the BDM able to read those too?

Do you have any idea how to recompute that checksum area info?

Many thanks for the response!