RomRaider

Hello all! Decided to post here to see if we can get some more support. Thread with more info -> viewtopic.php?f=65&t=16839

Would anyone be up for the challenge of seeing if this dump is of the full TCM ROM and if they’d be able to come up with a definition file for it? The TCM is made by Bosch.

Really the main maps needed would be for torque requested/demanded and the shift maps at WOT. The transmission shifts early in 1st and 2nd gear and for those of us with raised redlines, it’ll still only shift at 6600rpm. Manualmatic mode has a torque demanded 1 and 2 map that affects line pressure. So you can get fast as hell shifts in manual mode, while auto mode is still going to be slowed down. I’ve also heard that manualmatic mode has a delay tuned in. If this is the case, it should just be a single value that we can change. Similar to the WOT delay that we can change on our ECUs. So by being able to change those maps, we would be able to seriously improve our transmissions.

These things can shift as fast as 300ms. So being able to guarantee 300ms shifts during WOT while still being able to drive fuel efficiency would be incredible. (shifts are determined in learned driving habits so the harder you beat on it over time, the faster the shifts.

The TCM ID for it was CF40A And if the dump isn’t full, I could try to dump the rom again.

EDIT: Nisprog appears to be able to FULLY DUMP the TCM ROM! The file size is the exact size it should be for being MPC555. So dump times should be about an hour and a half to two hours.

That's pretty cool to have a TCM dump. What did you pull the bin with? looks like version BOSCH GS19 MPC555 inside of the bin file. I haven't even started playing with the TCM yet, just using a shift kit and stacking internal clutches to make it better. Would be nice to fine tune it though.

I actually pulled the bin using nisprog! Then I dumped it without using a kernel so it took about an hour and a half. I’m getting a shift kit in the future as well! But it would be so nice to get it to shift at 7k as well as making it fully rev up in 1st and 2nd gear.

This is great work . I have a tonne of these in Navara, Skyline , etc

Have you ever opened one of these tcm ?
Do they have an external memory for maps like every bosch/delphi engine ecu that used the MPC5xx chips ?

It’s crazy what’s possible with Nisprog. Crazy work. I have not opened mine up since my TCM is inside the transmission, unlike older Z’s. I also wouldn’t know what to look for but here’s a really good video that shows the internals of the TCM! -> https://youtu.be/HKyKyXWDb2s

Did you use setdev 0 or setdev 1?

makes no difference unless reflashing

Wow I never knew that. So no effect on any commands like dumpmem?

What exactly does setdev do if you don't mind me asking?

Cheers

It's no secret :

https://github.com/fenugrec/nisprog/blo ... cli.c#L246

it selects one element from the array definining the memory map (flash blocks) for each device here

https://github.com/fenugrec/nisprog/blo ... kend.c#L36

these block boundaries must be known for the verification and flash process which is done per-block to save time (only reflash modified blocks)

dumpmem doesn't care about blocks because it simply reads from the requested raw addresses.

MPC555 flash data might starts at 0x00 0000 and ends at 0x06 FFFF for flashing. According to https://www.nxp.com/docs/en/data-sheet/MPC555UM.pdf

This is what I believe was dumped since CMF Flash A (256kb) and CMF Flash B (192kb) combine to 448kb. It can be confirmed in IDA pro I'm guessing. Whenever we do confirm it's location, would flrom be able to flash the ROM back onto the TCM if the block boundaries were added to nisprog's code?

No, as explained elsewhere. Reflashing TCM's depends on 2 things being clarified :

- sequence of commands/requests to reflash (either log/sniff a factory reflash, or RE the ROM)é
- if required, an MPC555 kernel. Whether or not this is the case still needs to be determined, I have no idea.

I got nisprog to connect to the TCM on a TB48DE Patrol with an RE5. It also uses destaddr 0x18

This did not work for me:

dumpmem filename.bin 0 458752

Straight away I just got repeated:

Bad AC Response FC EC

Any ideas?

My nisprog.ini is very simple:

set
interface dumb
port \\.\COM3
dumbopts 0x48
l2protocol iso14230
initmode fast
testerid 0xfc
destaddr 0x18
addrtype phys
up

npconf p3 2
npconf rxe 200

nc

weird one. Try increasing npconf p3 to 5, then "debug l1 0x8c" just for this short test and "dumpmem 0 4 "

I received a loan TCM in the mail and it's got some old Unisia JECS chip on it

Unisia JECS PN: A12-212
Motorola? PN: SC431725CFC

Flashability is not looking good!

It is possible that this unit is identified (with all the consequences) not by K-Line but by RX / TX (Consult protocol).