RomRaider

TCM is 0x18, but I do want to try that out just to see what shows up!

It seems my RE5 TCM is very different but I finally removed the flash chip from my testing TCM and took a read of it.

Here it is if anyone is interested.

Already responded to your main post, but I’ll post any similarities or interesting info about it here as well! The more TCM dumps we have to try finding similarities and differences, the better! But TCM reflashing is looking to be something that won’t be as nice as ECU reflashing.

Wiki page https://nissanecu.miraheze.org/wiki/RE5 ... M_Analysis (not much as of 2/10, but I'll eventually transfer more over and add to it as time goes on)

//

So finally some more confirmation on what it all talks to. So it talks to the ECU through CAN line only and all K-line comms are directly to the OBD2 port. Not very revolutionary but I enjoy providing actual documentation instead of just telling everyone what’s going on lol

Edit; ignore the “2004-2008” nonsense. It’s already known that the year ranges are estimated to be 2002-2004, 2004.5-2005, and 2006-2008. All with different valve bodies. Pre-04 is the only external TCM models.

Saw there was some updates on the miraheze link. Thanks for keeping at it

@Fenugrec, since the only area we've successfully been able to dump is the CMF A+B Flash Areas, wouldn't this imply that reflashing this area would be done without the use of a kernel? So it would make total sense if we could reprogram without a kernel, but I dunno much about this stuff so far. I'm going to see if I can dump more than just the CMF Flash Area, but I'm pretty sure Nisprog automatically stopped dumping last time even with a requested dump data size higher than what it ended up dumping.

Eh, probably just that the TCM "ID" whatever (analogue of the ECUID) is similar enough to an ECUID in the masterlist. Probably doesn't mean much. Algo could be different, too...



I don't see how one could infer that based on accessible mem areas, but it's definitely possible that a kernel would not be required.




That is strange because EC is the positive response code for SID AC (0xAC + 0x40), and 02 EC 81 xx (xx=checksum) is exactly what the ECU would respond normally. Looks like it's mising a byte for some reason. Have you tried increasing read timeouts...



just 0xAC by itself is not very useful; if you don't format the AC request properly, all bets are off. I wouldn't even trust the neg response code.

I suppose due to how CAN-reflashing is handled. Where the bootloader(?) stuff isn't flashable, allowing you to recover a "bricked" ECU without needing to bench-reflash it. Also, since it allows you to reflash a CAN-based ECU without a kernel. But technically the two aren't comparable.



Not yet, but does AC give a separate response for "End of ROM Section"?

Good afternoon.
I apologize for my english, google translator.
I have Navara under repair, there is an ecu in the automatic transmission. There is mpc555. ECU defective, temperature sensor circuit. This malfunction is exactly in the ECU, I ruled out the rest.
There is another ECU available, but it does not fit, does not see CAN.
I want to re-upload the firmware from the old ECU to another. First, I need to read the old ECU. What needs to be changed in the ini file so as not to accidentally erase the firmware?
The machine has been out of order for 6 months, please help.
There are KKL, OP2, X-Prog.
Attached is a photo of my ecu

While I'm not very confident that it'll work for you, changing the destaddr to 0x18 and removing the runkernel and setdev commands would be all you'd need to do. But that TCM looks nothing like mine haha So it's probably going to be similar to Bradsm87's where he wasn't able to dump the ROM with Nisprog. Wouldn't hurt trying though!

The only thing he would be able to accomplish is maaaybe dumping the ROM (not even certain). @andrey, nisprog cannot reflash anything with a MPC555, only certain SH705x-based ECUs.

To answer one question directly:

accidentally erasing the firmware is extremely, extremely improbable .

Given how it looks like an external TCM module, I highly doubt it can be dumped. Speaking of which, could Nisprog use $23 rather than $AC to dump the ROM image for TCM's? Reason I ask is because the TCM supports $23 and maybe even $3D, but I'm not sure if $23 and $3D are RAM exclusive or not.

I found out that my adapter is not working as expected. I watched the ECU replies after the request, there are none. I will try with another adapter.
I checked the LAUNCH scanner signals with an oscilloscope, they are, but my KKL sends a request and does not receive a response. I will plug in a logic analyzer and record the requests from the scanner and compare them afterwards with the NISPROG requests.

Good afternoon.
I got the readings from the logic analyzer. On the scanner, the time between request bytes is 9ms, on the NISPROG it is 7ms. The duration of the pulses themselves is the same for the scanner and NISPROG.
Maybe that's the problem. Can you fix this?

The scanner receives a response only after the second request. The requests are the same, but the answer comes only after the second. Perhaps two requests need to be sent. The second request is 330ms after the first.