Members Login
Username 
 
Password 
    Remember Me  
Post Info TOPIC: Flashing the ECU...


Guru

Status: Offline
Posts: 2338
Date:
Flashing the ECU...


I think that there is enough information to proceed to consider testing the flash writing in boot mode using the harness connector. The harness connector has all the required hardware signals to use Renesas FDT (Flash Development Toolkit software) traced back to the processor. This is very much in line with Renesas saying that recommended method for flashing the sh7052 processor is over serial line. The user mode can not be used as the user mode microkernel does not seem to be present with the Denso/Suzuki sh7052 code.

There is three key questions anyhow to be considered before proceeding:
1) Is it likely that the FLASH image downloaded using AUD differs from actual FLASH contents? E.g. if there is a relocated areas giving false FLASH reading using AUD connector when the user program is running ?
2) Is it likely that there is a proprietary type of bootloader software that is not accessible using AUD connector. So that after I flash the ECU it does not anymore boot ?
3) Is the downloaded program code consistent enough to be rewritten? There is a lot of areas with 0x00 in the image, which surprises as in boot mode the Flash is initialized into 0xFF's, if I remember correctly ?

Any comments about the above ?

The way I see it is that by hooking up the processor into the EPROM mode would allow reading the sh7052 Flash without the user (ECU) program running. Anyhow that is quite extensive excerisise so maybe there is another approach to investigate this matter further ?

So far I have succesfully downloaded the Flash contents from Hayabusa K5EURO and K6USA ECUs. Based on some educated guessing also I can expect that the K6USA ECU is not equipped with Oxygen Sensor hardware where as K5EURO has Oxygen sensor. These flash images are similiar exept on the map part of the image.




__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Guru

Status: Offline
Posts: 2338
Date:


I can confirm the reprogrammability of Busa ECU using serial line from harness connector.

After some "careful" consideration and with lack of opposing advice I just decided to go ahead with reprogramming (flashing) the K6 busa ECU using serial line.

Powered on the ECU. Checked with Scope that the serial data to gauge cluster is present indicating that the ECU is good.

Connected the Max232 based RS232 converter to PC, started up Renesas FDT4.0 and loaded the BusaK5EU code into FDT. Set up FDT with sh7052 default settings.

Set FWE, MD1 and pressed reset, the serial data stopped.

Pressed Connect in FDT with defalt settings and the connection to ECU was established. Downloaded the Busa K5EURO bin to Busa K6USA hw. Reset FWE & MD 1 and pressed reset. The Scope became alive again indicating that the serial cluster data returned.

Connected AUD interface and reloaded the last few bytes to verify the new flash contents. The new readings from K6USA ecu was read as K5EURO.

WAS K6USA=BB34BB35
S3090003FFF0 4242 3334 19
S3090003FFF4 4242 3335 14
S3090003FFF8 2256 FFFF 86
S3090003FFFC FFFF FFFF FC


NOW IS K5EURO=BB34BB51
S3090003FFF0 4242 3334 19
S3090003FFF4 4242 3531 16
S3090003FFF8 1543 FFFF A6
S3090003FFFC FFFF FFFF FC


EDIT - of course there may still be complications. One to anticipate is internal checksum calculation which has been present on some ECU:s. The next tests need still to be completed to check the ability to write modified maps:
1) Write a modified map into ECU and check that the ECU still boots and gives gauge cluster serial data.
2) Verify the full EPROM contents by reading through AUD.


-- Edited by PetriK at 21:47, 2007-12-06

__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Guru

Status: Offline
Posts: 964
Date:

Congrats. That is a major accomplishment that took some guts to try. But no guts no glory as they say.

I wouldn't worry about a checksum. It would be kind of pointless. Since we are reflashing the code and the map we could just remove any checksum routine in the code when we reflashed it. Knowing it would be that easy to defeat I wouldn't bother to put one in if it was me.

I think the encrypted ECUs are mostly limited to the ones with the external EPROM chips that can be removed from the board. And many of those the 'encryption' was just swapping some of the data pins on the circuit boards so the data would look different to the CPU than to a standard wired EPROM burner.

Again, Good Job!

__________________


Veteran Member

Status: Offline
Posts: 80
Date:

Congratulations from me too!

This is indeed a milestone.

Mark.

__________________


Guru

Status: Offline
Posts: 2338
Date:

Thanks mate(s). I was too very proud but also very surprised how easy it was.

So lets summarize how this can be done with some simple words and documents.

The ecu needs to be put into the boot mode for programming. It happens with setting two signals FWE and MD1 and then pressing reset. All these signals are named on the harness connector accordingly.

Harness connector

harness pins


Then we need a simple RS232 to TTL converter, e.g. using the following schematics.
ttl converter

Switches for fwe to be connected to +5v and md1 and reset button to connect to the gnd as below:

The programming modes need to be set according to this attached picture fron Renesas sh7052 hw guide. Currenlty the only working option is to use the boot mode
proc prog modes
With busa seeing if an ecu is alive is very easy. There is bursts of serial data to gauge cluster from the ecu.

gauge data

As the last document, before trying the programming you can check that the components for programmability are installed with this:
http://macmadigan.no-ip.com/Public/ECU/Busa32bitECU_programability_test.pdf

The software FDT4.0 can be downloaded from here:
http://www.renesas.com/fdt

I hope that the above gives all the needed information tools needed to build a simple but working programming environment.

__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Veteran Member

Status: Offline
Posts: 80
Date:

I note on the SV's ECU that I only have access to an FWE pin, and MD1 is not brought out to the harness connector.

Upon tracing the FWE pin, I find that it:
(a) connects to pin 28 (FWE) on the 7052 (via a resistor), and
(b) drives transistor T904 that pulls MD1 low.

MD1 is connected to +5v via a pullup resistor, and is also connected to the (I assume) collector of T904. The emitter is earthed, the base is connected to FWE via a resistor, and there's a resistor R921 between base and emitter. (I'm guessing at the C,B,E terminals here, assuming it is an NPN).

So I am postulating that if I pull FWE high, then the voltage across R921 will turn T904 on, effectively putting a '0' on MD1. I haven't tested this (yet). That means the procedure for the SV's ECU would be to pull RST high, then pull FWE high, then release RST to get into boot mode.

Alternatively, it looks like going from user mode into user program mode only requires pulling FWE high (the state map doesn't specify any setting for MD0..2 for this transition).

MD0 and MD2 are permanently wired high on the ECU cct board.

On another note, the propeller can be quickly configured as an oscilloscope ... check this out ...
http://mydancebot.com/viewport/index.php


Cheers,
Mark.

__________________


Guru

Status: Offline
Posts: 2338
Date:

bozo wrote:

Alternatively, it looks like going from user mode into user program mode only requires pulling FWE high (the state map doesn't specify any setting for MD0..2 for this transition).


The propeller looks increasinly tempting smile.gif)... but propably learning a new environment may cause delays with progress so I must resist...

Regarding user program mode, that requires user program mode microkernel being present together with FWE state detection program - something that was not in at least Busa ECU code. Therefore only the Boot mode was available, which at connection downloads the boot mode microkernel and then erases the eprom (hence the need for AUD interface to read the flash contents). But you may be luckier ... ?






__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Guru

Status: Offline
Posts: 2338
Date:

The local hacker just reported that he succesfully followed this process and reprogrammed his Z1000 ecu.

z1000z1000
z1000
z1000

-- Edited by PetriK at 03:20, 2007-12-08

__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Member

Status: Offline
Posts: 7
Date:

Has anyone mapped the pinout for the ZX-6R/RR ECU (I believe its the same pinout for the z1000 ecu)

The Busa pinout does not match the connectors on my 05 ZX-6RR ECU.

I have two connectors, a dual row 34-Pin, and a dual row 26-Pin on this ECU.
The Denso Label states:
21175-0066
112100-2570
12V TBCF56

I can get most of the pinout from the bikes electrical schematic, but the unfilled pins in the harness, I don't know. Perhaps someone who has unpotted a ECU with this connector arrangement can trace the board and fill in the gaps?

I am currently building up a picture with the pinouts as I know them. Will post when I got it done and we can fill in the gaps.

-Jerry


__________________


Member

Status: Offline
Posts: 7
Date:

bozo wrote:

I note on the SV's ECU that I only have access to an FWE pin, and MD1 is not brought out to the harness connector.

Upon tracing the FWE pin, I find that it:
(a) connects to pin 28 (FWE) on the 7052 (via a resistor), and
(b) drives transistor T904 that pulls MD1 low.

MD1 is connected to +5v via a pullup resistor, and is also connected to the (I assume) collector of T904. The emitter is earthed, the base is connected to FWE via a resistor, and there's a resistor R921 between base and emitter. (I'm guessing at the C,B,E terminals here, assuming it is an NPN).

So I am postulating that if I pull FWE high, then the voltage across R921 will turn T904 on, effectively putting a '0' on MD1. I haven't tested this (yet). That means the procedure for the SV's ECU would be to pull RST high, then pull FWE high, then release RST to get into boot mode.

Alternatively, it looks like going from user mode into user program mode only requires pulling FWE high (the state map doesn't specify any setting for MD0..2 for this transition).

MD0 and MD2 are permanently wired high on the ECU cct board.

On another note, the propeller can be quickly configured as an oscilloscope ... check this out ...
http://mydancebot.com/viewport/index.php


Cheers,
Mark.



I have been working with H8/300 processors for almost 10 years. This is the method we use on our H8/300 based hardware to kick into programming mode. We have a single line that we pull and a circuit sequences all the pins including reset automatically to get into boot mode.

You then download a boot program into user RAM which the H8 executes. The program can be anything you want, you can read/write FLASH/RAM as you see fit.  THis is exciting, I have alot of experience with the H8 serial boot mode.  I offer my services to write a Windows program to read/write flash. It's not that hard. If you use the Reneasa program, it is quite limited.  Best to write your own bootloader and interface so you can do alot more than just write to FLASH.

-Jerry




__________________


Guru

Status: Offline
Posts: 2338
Date:

Excellent Jerry - good to have you here ! If you PM me with your email I get you a jump start with some renesas file libraries...

I just posted another message about the user mode microkernel here:
http://www.activeboard.com/forum.spark?forumID=99460&p=3&topicID=14964147

Do you happen to know how the User Mode microkernel that comes with FDT should be called from the main program inside ecu to activate it ? I understand that it should be loaded into the memory but have not yet found any references of what activates it ???





__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Member

Status: Offline
Posts: 7
Date:

Petrik, how do I PM you, I can't find the link?

In response to th question about the user mode kernel, you don't need that.
We should use boot mode, which is easy to access and already designed into the ECU. I put a longer answer into the other thread where I posted.

I will start putting togethor a program to do this. I just need to learn the SH processor first and find a free SH compiler. From first glance it looks like they have not changed this interface since the H8, I may be able to use code I allready wrote for the H8 and just recompile for the SH.

-Jerry

__________________


Guru

Status: Offline
Posts: 2338
Date:

check your whiteboard on the main page top right corner... or alrenatively click my name and create a whiteboard message...

-- Edited by PetriK at 21:05, 2008-01-13

__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Guru

Status: Offline
Posts: 2338
Date:
sh7052 programming tools


Here you are with links to the programming tools:

Full compiler environment - after 60 days evaluation period limited to 256k code:
http://www.renesas.com/hew

All the microkernels come as part of the fdt installation.
http://www.renesas.com/fdt

After installing the FDT you will find the sh7052 related microkernels including source code from your local directory like this:
C:\Program Files\Renesas\FDT4.00\kernels\ProtB\7052\Renesas\1_0_00


So basically if I understand this you can just download the boot mode kernel and exlude the erase code to be downloaded from the pc to the ram ? So e.g. Gene7052.cde could be changed to read flash and dump it out - basically same commands as in user mode kernel ???

kernels.JPG


__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Member

Status: Offline
Posts: 7
Date:
RE: Flashing the ECU...


Thanks for the links.   Yes the idea is to exclude the erase code from the boot mode kernel, however after reading the hardware manual in depth, I can see that this processor has a built-in erase function that activates before the boot mode kernel runs. We are therefore screwed, which sucks.

The old H8's did not do this.

I am gonna think about this some more and see if I can think of anything else we could do.

-Jerry

__________________


Guru

Status: Offline
Posts: 964
Date:

jcd4878 wrote:

Has anyone mapped the pinout for the ZX-6R/RR ECU (I believe its the same pinout for the z1000 ecu)




 Did you check out the ZX-6 forum? Don has depotted the zx-6 and posted photos. I don't know if he's posted the pinout yet but I'm pretty sure he has traced them out.


I would post this request there.

__________________


Guru

Status: Offline
Posts: 2338
Date:

Yes - it looks like that there is an erase step before transferring the control to the user program.

So it leaves at least two alternatives:
1) There is a program for erasing that is part of the code that FDT downloads to the processors RAM. It is possible that this code that resides at PC still is used for erasing the memory. In that case modifying the erase program to do nothing could help.
2) Include the user mode kernel into the firmware and create a jump there. Including is fairly simple. The user mode kernel is compiled ready for a memory area which is empty, almost looks like it has been there when designing the program. Anyhow I dont know exactly how it should be activated when its in the memory. Could not find an interrupt for FWE or MD1 at all - or maybe its the serial port 1 interrupts that should be redirected to the user mode kernel ?

__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Guru

Status: Offline
Posts: 2338
Date:

or a third alternative...

Looked into serial protocol 3 in busa code, looks like it:
1) can receive and process received strings
2) has a pointer to ram variable, so possibly it can write/return the ram variables while running

Understanding the SCI3 protocol more in depth requires assembler skills beyond my level. But I would be interested in to know if any other ECU programs can take in SCI3 or other serial protocols and process those. Maybe there is a way to do something by utilizing the SCI3 protocol for tuning. At least on some ECU:s. (in earlier busas the hw was left out from the circuit board so this must be also looked into) as well as to understand what is the speed of the protocol....


Here is the part of the code that to me looks like returning either ROM ID or RAM variable that has been pointed. This is part of the SCI3 RX processing.

ROM:00011626 Read_RAM_variable_sub_11626:            ; CODE XREF: sub_41D0+8Ap
ROM:00011626                                         ; DATA XREF: ROM:off_42E4o
ROM:00011626                 extu.b  r4, r3
ROM:00011628                 mov.l   @(h'48,pc), r6 ; [00011674] = addr_of_first_RAM_variable_dword_15560
ROM:0001162A                 mov     #h'54, r2 ; 'T'
ROM:0001162C                 cmp/gt  r2, r3
ROM:0001162E                 bt      rom_id_loc_11636
ROM:00011630                 extu.b  r4, r0
ROM:00011632                 bra     return_loc_11638 ; ROM ID
ROM:00011634                 shll2   r0
ROM:00011636 ; ---------------------------------------------------------------------------
ROM:00011636
ROM:00011636 rom_id_loc_11636:                       ; CODE XREF: Read_RAM_variable_sub_11626+8j
ROM:00011636                 mov.w   @(6,pc), r0 ; [00011640] = h'150
ROM:00011638
ROM:00011638 return_loc_11638:                       ; CODE XREF: Read_RAM_variable_sub_11626+Cj
ROM:00011638                 mov.l   @(r0,r6), r5    ; ROM ID
ROM:0001163A                 rts
ROM:0001163C                 mov.b   @r5, r0
ROM:0001163C ; End of function Read_RAM_variable_sub_11626



-- Edited by PetriK at 16:14, 2008-01-14

__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom

Page 1 of 1  sorted by
 
Quick Reply

Please log in to post quick replies.

Tweet this page Post to Digg Post to Del.icio.us


Create your own FREE Forum
Report Abuse
Powered by ActiveBoard