RomRaider

This is needed to protect your ecu\FTDI chip when they are not powered from the same source.

Edited: misprints...

Thanks Sasha!

Got aquestion about the frequency of watchdog signal.
Here we talk about 125Hz, in nasioc.com forum they talk about 150Hz.

Witch one is correct, or better in with range the watchdog has to be ?

I working on a read-and-wirte interface based on arduino UNO for AUD-reading and SHBootmode wirting.
I can bend the frequency of the arduino PMW out (to use as watchdog) in fix clases. 122,549Hz is the frequency, who´s next to the one I found in this description .

Does this also work ?

BR

50-60 ms max period is applicable for Denso ecu watchdog.
That means you are free to choose convinient WDT frequency.

I've found anywhere between 125-150Hz works well. I believe I saw the 125 spec on the tactrix website.

Thanks for your hints..

Comming to this again:

arduino got 1kOm in RxD /TxD lines. Is this enought or should I put add on resistors to communication lines ?

Watchdog will be a push-pull output of arduino with a 5kOm resistor.
But what about FWE ?
Tractix shematic seems to show resistor on ECU, so I can connect +5V (pull-output of arduino) directly, or better to put a 1kOm in ?

MD1 needs to be switch to ground. Normaly without resisor ?!

Wireing of PIASINI-Tool describes just bridges between Vcc to FWE and ME to GND. But AFAIK this will only work, if Vcc got only one scource

In activeboard it was said, no resisitors need to be put in, when reading AUD via arduino, but I am not really sure about that.
Importents part is not to kill the ECU be connection the interface


BR Jochen

Use ECU Vcc and GND for FWE and MD1. This is not a problem.
1 kOm for Arduino RX is quiet applicable. 1 kOm for Arduino TX is probably too high. Sometimes it needs to be less (probably this is related to ecu\ambient temperature).
5 kOm for WDT is applicable, it should not be less.

AUD lines should not use more than 330 Ohm protective resistors.

But this needs to use a add on relais.
The push-pull-outputs will provide + 5V and GND.
GND is not a problem because it is connected to GND of ECU. + 5V is supply of arduino, so maybe there will be a problem without a limitation of current to FWE.
I see on Subarutech77 picutures a direct connection form + 5V form Interface to ECU FWE.
Seems to work ?!


I will check, the resitors are part of the board. If it doesn´t work, I need to change.

If 10kOm is better, I use this

ok, I will set them down

WDT pin is tied to Vcc by 47 kOm.
Thus 10kOm is to high and does not provide needed '0' voltage level.
Too small resistance is also not applicable since WDT has active signal on the board while ecu software is running. 3-5 kOm resistor is applicable.

It is not allowed to directly supply +5V externaly to any processor pin if there is not protective resistors.
I would recommend use resistors for grounded pins as well.
Just GND net should be connected directly.

Just a new question to SHuBootMode, or better to the dump, with should be written.

AFAIK the dump should be "complete", witch means correct size, kernel inside, CS ok, etc.

There are some new tools reading the SH7058S and SH7059 of the Diesels via OBD and will not read the kernel (CMD or Alientech e.g.) The size of the CMD readout is correct, only the kernel part is "FF" as well as the first line of the dump is renamed to "CMD-MCD"

Alientech tell my, that there is no problem in recover the SH7058S without the kernel. So is it possible to use the read-out of CMD or Alientech without the kernel at the frond of the dump as the dump basis of SHBootMode recover, if the dump size and CS are correct?

Who is Mr. CS ? Do you mean CheckSums ?
Is VBR table at the end of ecu dump read ?

If answers are positive an experienced programmer is able to make the image bootable and working.

correct, checksumm


Who is Mr. VBR ?
The dump beginn at 0x0 and ends at 0x17FFF, so I think it is complete for SH7059 one. The kernel area is "00".
Ending of EURo4 complete and EURO5 incomplete seems to look simular.

In case of the EURO4 dumps, I got complete ones (read via AUD), so I can copy the kernel into a dump with a missing one.
Two differned readouts of OEM software show the same kernel, so I think this will be not problem.

In case of EURO5 it is differnd
So maybe you can give me some hints to this ?

What I do not unterstand:
the way SHBootMode works and why it needs a complete dump is clear. If I got a brigged ECU AFAIK the OBD does not work, because there is no software working on the controler.
But as I unterstand Alientech recovers via OBD brigged ECUs and do not need more, then they are read now, so no kernel..

What is the differnce ?

I know for sure you are mislead.
"Properly" bricked SH based ecu could not be recovered thru OBD.
There probably is a chance to recover an ecu with the alive primary bootloader ( CAN bootstrap loader in case of Denso ecu ).



VBR is VectorBaseRegister.
Denso put the InterruptVectorTable at the end of the code and does not provide the way to read this table thru SSM request.

I think so, maybe because they had a working way, witch is unsimular to the Denso way, but it works in a way what ever.
And on the other hand, "simple" tools will do the same job, witch they will not confirm..


O.k. this can be the way they went, but for this I also need a complete dump with kernel, or am I wrong ?
Other question:
what will happen, if I would recover with one of these dumps without the kernel ?
Software, maps, size and checksumm will be o.k. and the kernel is not need for normal work ?



With the SSM request I can only read the application area with all the 2D and 3D maps.(EcuMem Tools e.g.)
As I (tryed) to unterstand, the VBR should be after the checksumm table.
If yes, then this part as well as the the checksumm table, the source code and everything else is reat.
Only the first 16kb with the kernel is missing.

SH boot mode will completely erase the ROM, full ROM image is needed to restore. This is used when an ECU is bricked.
SH User boot mode will not erase ROM and requires the user to upload a client program to the ECU to selectively erase/program memory upon instructions from a server program on a separate computer with the image data, comms is via CPU serial 0.