Vida CEM swapping

[FullCircuitDiag]

You probably have a good read. 320kB.
M30855FW ROM starts at FB0000.

So is that where I got lost in my addressing of the bytes? Are everyone’s addressing they quote for locations of pins and cypher keys assuming you aren’t looking at the dump via a BDM programmer screen? Because my read starts at 00000000. Should I just offset everything by the value 00FB0000? Then continue to use the addresses that are quoted in the section for decrypting the EEPROM?
THANKS!

[rkam]

If you put the code where it is at in the CPU when running, the key would be at FFFF00.
That would be 04FF00 in your file I guess.

Those with a 512kB dump would find it at 07FF00 in their file.

[dikidera]

I was digging for info today. The SH7055 and in general all SH CPUs do have a JTAG interface, but only partially, there are hidden commands and conditions in order to fully take control of the chip, but it's all proprietary and hidden behind NDAs, it's why their debug interface is called H-UDI(Hitachi User Debug Interface) and not strictly JTAG. And only their special hardware or other third party tools can actually read/write to registers and so forth for true JTAG.

The information about debug functions using H-UDI is no public information. This is being shared only with some few companies. Information about the debug interface is not part of the device manual.
I don't know this Codescape debugger, and I find no mentioning that it supports SH4. So I assume it doesn't.
If you want to debug SH7750 I believe you should have an E10A-USB emulator or a Lauterbach emulator.

So yeah, E10A,Lauterbach or PalmICE SH7055

But googling I also found this tool https://github.com/v-ladimir/audprog to interface with...exactly the 7055 MCUs AUD interface. The AUD interface is good for reading/writing memory, but I'd imagine it's still limited to RAM.

It may seem it has nothing to do with ECU tuning, but for me most of the RAM addresses and no xref functions lack context. JTAG would've allowed me to trace the execution and find out important stuff, but at least the JTAG stuff are out of the question.

[oscilloscope]

Little of topic but does someone have software to read and write magneti marelli throttle body with Dice? Or does someone know the memory size and adresses to read?

Not via DiCE , I have the etm programmer. Its useless without the programmer. , too add I'll have to check the software, I don't think it gives the expected memory size until its read it. I don't use it very often.

[FullCircuitDiag]

If you put the code where it is at in the CPU when running, the key would be at FFFF00.
That would be 04FF00 in your file I guess.

Those with a 512kB dump would find it at 07FF00 in their file.

Thank you so much!
Now just for the sake of learning, can you tell me how you figured out where the code is at vs running vs not running and pulled via BDM? I'm trying to make sure I fully understand how all the data moves around this processor.

[FullCircuitDiag]

Also I'm trying to find the decryption key that they reference being at 7FFF0-7FF30. What key are you talking about being at FFFF00? Right now my main goal is to decrypt the EEPROM data via a hex editor and board level programming NOT through the OBD port.

[rkam]

7FFF0-7FF30 must be a typing error. It doesn't make sense.

FFFF00 to FFFF3D is used as far as I can tell.

[rkam]

The memory layout is in the Renesas documentation of the CPU.
I suppose your bdm tool will just store the 320kB of data when you save it as plain binary.
If not, it would be a 16MB file.
Other formats like HEX, MOT and S19 could include address data while still remain smaller than 16MB.

[rkam]

I made an excel spreadsheet to decrypt the eeprom many years ago, so I'm a bit rusty.
The spreadsheet looks more complicated than needed.
I think it should be something like

(data) xor (rotating key byte 0-60, 0-60, 0-60 ...) xor (low byte of eeprom byte number / 7)

[rkam]

@Dudde
I found a Magneti Marelli ETM002-01 1ALC913CC in my garage with an OBD connector attached, so I have probably read it before sometime.
Now I am reading from 0-10000 to see what I get.
I don't know what kind of CPU is inside, but it looks like there are interrupt vectors from address 0.

Reading is by checksum method in PBL with DiCE. I couldn't find any SBL now.
250kbps Address 0x12 response 0x11

Part number 8644347 it says when asked.

Result so far
000000-020000 FLASH
040000-041DFF RAM

In normal running mode the ETM understand the following commands. (Disassembled as 68330)
A0: Stop Diagnostic Session
A1: No operation
A5: Read Current Data By Offset
B8: Write Data Block By Offset
B9: Read Data Block By Offset
BB: Read Data Block By Address
BA: Write Data Block By Address

A50101 returns E501: 03 7c 09 68 01 02 75 2D 9F 00 30 78 51 80 20 20 41 00 00 18 9F
Possibly live data and ECU Software number.

You can read from Flash and RAM with BB command
BB 00 40 00 10 will read 10 (16) bytes from address 004000 in Flash
FB 00 40 00:00 00 08 64 43 47 20 20 42 FF FF FF FF FF FF FF

You can also write to RAM:
BA 04 00 01 02 AA BB will write 02 bytes AA BB to RAM address 040001