RomRaider

Nah I think you're fine, you should've seen AKEyes' ECU when he finally killed it !



Hmm, not so sure... it depends if Q904 is an NPN, and where R912 connects to - base or collector. If your multimeter has a diode test function, can you confirm the pinout ?

You *could* try removing R912 but it's glued there and finnicky to remove if you haven't worked with SMD much (practice on some scrap PCBs before !) Plus, it's a long shot anyway without seeing more of the circuit traced.

Also I see you labeled "TX" on both sides of R900, which one goes to the mcu pin ?

Here's what's going on in that bottom corner. Above that, both go straight to HL17 and HL18 and over to the MCU. Circled some points the same color to ease matching top/bottom

I suspect RX TX marking on PCB corresponds to UART and not MCU.
And you may short red marked point to ground to disable TX to Kline path.
Just short C985 capacitor.

Q904 does not look like a correct RX driver.
I think Q900 is. And you are to short R903 resistor to block RX path to MCU from Kline.

Anyway you may send the ecu and applicable ROM image to me for recovery if in doubt.
Upto 2 weeks each turn by a snail mail postage.

Did some multimeter testing since those traces can be so tricky. Here's what I've found connected from MCU pin 165.

yep, definitely need pencil & paper when tracing a multi-layer PCB ! you seem to have done well, but on Q903 you have the arrow drawn on the wrong leg (goes on E, which is probably ground, which makes the circuit make a bi tmore sense.

Two things you could try, remove the 22k resistor going to TxD (I don't even understand what they're doing there), or better short B and E on Q903 which effectively deactivates it.

Hi to all)
One man write to ECM of Nissan teana J32 2008Y with SH705822/28 firmware of Nissan Murano Z50 2007Y with SH705821 - ECM is bricked
He thinks - WTF!? and try to write it in another 3 ECM
Now we have 4 bricked ECM of Nissan Teana J32 2008Y with SH705822/28.
Then he send 4 boards to me to unbricking it
He write it with K-Tag.
I try to connect with FDT, Boot is ok, but then i have an error with "sending supported devices inquiry", what is this?
http://www.picshare.ru/view/10246032/
I unbrick Nissan Note E11 ECM with SH705520, and Nissan Teana J31 ECM with SH705513 - no problem with it.
TPs pins are the same as on another Nissan ECM (photos later).
FWE=1
MD1=0

Did you try using "generic" kernel instead of selecting particular 64F7058xxx device in FDT?

I had such issue once for 0.18um CPUs - some of them were requiring exact selection of 64F7055xxxx while others were working only with "generic type C kernel CPU" or something like this.

Another possible reason - SCI1 which is used for reflash via FDT is also used for other communications inside ECU and components like EEPROM/WDT could affect the line communication. I got one ECU which uses SCI0 for KLINE and SCI1 for EEPROM communication.

Error on your screenshot looks like resulted by second reason.

Use GenericBootDevice.
If nothing helps it is high time to visit my location.

I try "generic" and 7058, result is one - fail.
Eeprom 95320 is connected to SCI0. I desolder it, - nothing's change.
If i try another CPU - then i have an error "bla bla bla 0.18um CPU".

I uses it, but nothings change.

May be later)

Clock Frequency (External) = 10.0000MHz, Clock Mode = 0, CKM = 4, and CKP = 2
Connecting to device 'SH/7058F' on 'COM7'
Configuration:
'BOOT Mode' connection - using emulated interface
Opening port 'COM7' ...
Loading Comms DLL
Loaded Comms DLL
Initiating BOOT SCI sequence
Attempting 9600
Received immediate response from device: 0xE6
Detected generic boot device
Sending inquiry for getting line size
Buffer size has been set to default (128 bytes)
Sending selection of device command
Selection of Device - Device selected, code 0601
Sending selection of clock mode
Sending selection of clock mode
Selection of Clock Mode - Clock selected, code 0
Changing baud rate to 57600 bps
Error No 15005: 'COM7' read time out
Error No 15016: Changing baud rate to 57600 bps

It looks like the watchdog circuitry is not working properly and the chip is reset while erasing the ROM before baud rate switching.
Alternatively your COM7 interface may loose "erase done" response. It may take place for FTDI USB chip not set properly.

I connect WDT circuit to another working ECU - nothings change.
FTDI ft232rl - original but very older chip.
I think try to buy another FTDI chip to compare result))

You can also try the manual steps on
https://nissanecu.miraheze.org/wiki/Boo ... operations
and repeat the 0x20 , "Supported device inquiry" a few times over a few seconds, that should confirm if the WDT works or not.

WDT on Nissan MY08+ ecu relies upon WDT clocking AND SCI port communication with throttle control chip.
You may analyze ecu bootloader code.

Is it so-called "Gen2" ECUs? Based on SH72531/SH72543/R5F72533 or it is still about SH7055/SH7058-based ECUs?

The remark is about SH7058S based Hitachi\Nissan MY08+ ecu.
I have no experience with the most recent ones.