[blackoak]

Hello,

I'm trying to backup a rom image from a EEC-V (Ford Puma 1.7, 112K) using PTDIAG and a EEPOD MCS1 which talks SCP.

I've worked out it's 112K as the module id reports as "AXPDCB2.HEX*..XS6FAHB*" whereas other sizes were blank or garbage. That looks to me like strategy AXPDC (release version of AXPD2) and the part number was XS6F-12A650-AHB?

I can also pull memory regions off (slowly!) But I've no idea how the memory is mapped and what I need to be able to flash back on another module later.

It seems happy enough starting at address 0, but I can also start at 0x10000000, so I presume the memory is laid out all over the place as with any modern ECU. I presume when pulling via SCP the module will do whatever bank switching is required to map these regions to physical rom.

Can anyone guide me in what regions need to be downloaded to build a complete dump of the rom please? Or perhaps if anyone has a hex dump from a Puma I can compare how the memory addresses translate.

Many thanks

[jsa]

That looks to me like strategy AXPDC (release version of AXPD2) and the part number was XS6F-12A650-AHB?

Yes those are strategy and part number.

I can also pull memory regions off (slowly!) But I've no idea how the memory is mapped and what I need to be able to flash back on another module later.

Inernal to the EEC for 2 banks, it will be

bank 1: 12000 to 1ffff
bank 2: 82000 to 8ffff

It seems happy enough starting at address 0, but I can also start at 0x10000000, so I presume the memory is laid out all over the place as with any modern ECU. I presume when pulling via SCP the module will do whatever bank switching is required to map these regions to physical rom.

Being able to start at 0x10000000 must be a function of the PTDiag you are using.

Can anyone guide me in what regions need to be downloaded to build a complete dump of the rom please? Or perhaps if anyone has a hex dump from a Puma I can compare how the memory addresses translate.

Many thanks

It's really a question of how does PTDiag translate user input to SCP. I'm not familiar with PTDiag.

I'll have a look for a bin a little later.

[jsa]

Both the same strategy but different catch codes. Both will be the same memory layout.

AXPDCB3.zip

(76.97 KiB) Downloaded 79 times

AXPDCE4 and SAD output.zip

(295.48 KiB) Downloaded 76 times

You may find the SAD output files interesting if you are not aware of SAD yet?

[blackoak]

Thanks very much John, that was very useful.

I compared your BIN file and it aligns with what I've read at 0x12000 and 0x82000. So I'm pretty confident I've got the full dump of data.

Unfortunately, PTDIAG dumps the data in a text file as ascii hex, something between what you see in a hex editor and an intel hex file, so I'll need to write a little program to convert that into a h32 (hex) file for flashing back on.

I also noticed that SCP seems to support DMR, i.e. reading live RAM memory locations. Do those SAD files help you find memory locations for common parameters (N, LOAD, LAMBSE, etc?).

Notes for history: PTDIAG reads about 20 lines of hex to the screen before freezing and hanging. Don't panic just let it do its thing in the background and it will come back when finished. Also note memory start address is in hex but the memory length is decimal, in this case 57344 bytes. SCP protocol worked out the box by changing in "Setup" -> "General Configuration", but you need to do this every time you load as it reverts to CANbus. This tripped me over at first, I thought I'd bricked the module!

[jsa]

Post up the ascii hex file from PTDIAG, I might have a way to generate a binary file or intel hex file already.

ForDiag can read and save binaries via scp. Moates QH or BURN2 & FE can read and save binaries via the J3 port. The QH does live emulation / tuning / logging.

Yes that is the purpose of SAD (Semi Automatic Disassembler). The SAD output files posted before are the default auto output, before user DIRection.

Here's an example of a bin with all parameters located in memory, with user DIR file.
https://github.com/OpenEEC-Project/EEC-IV_A9L

Here's the repository for SAD. Version 4.13 is the best choice for now. There are newer development builds but they have issues which are being worked on.
https://github.com/tvrfan/EEC-IV-disassembler

Where is PTDIAG available from?

[blackoak]

Thanks John. I wrote a quick util to convert the ascii to hex.

I built up a hex file that had two memory regions 0x12000 to 0x20000 and 0x82000 to 0x90000.

PTDIAG is an internal tool and is meant for people who know/can remember what they're doing!

It started the flash process by erasing the memory. Then stopped when it tried to flash with CONDITION_NOT_CORRECT.

So I've now got a blank module, but thankfully the bootloader still seems to be there as I can still read/write memory.

After some trial and error I found that the first bank seems to be at 0x2000 and by shifting the region down to 0x2000 to 0x10000 I can get that bank to flash.

However, the second bank I've not found where it wants to go. I've tried making it contiguous with the first bank at 0x10000, and offsetting it by 0x10000 to 0x72000. But not luck.

I do remember seeing a post somewhere talking about the relative address offsets of file and use including 0x2000 mapped to 0x12000, but can't seem to find it again!

TLDR;

For 112k EEC V:

Bank 1 maps 0x12000 to 0x2000 in rom
Bank 2 maps 0x82000 to ????

Many thanks

[jsa]

Would you share your ascii to hex util on github or here?

Inernal to the EEC for 2 banks, it will be;
bank 1: 12000 to 1ffff
bank 2: 82000 to 8ffff

Good luck with remembering the addressing scheme in PTDIAG!