Members Login
Username 
 
Password 
    Remember Me  
Post Info TOPIC: First attempt at using an M32R in boot mode to flash.


Guru

Status: Offline
Posts: 963
Date:
First attempt at using an M32R in boot mode to flash.


The following is based on my attempts to flash the Busa 32920-15H10 which uses the 32196F8 MCU by Renesas.

I'll summarize first then go into details. This is a good news / bad news kind of post.

cry You can not use the Flash Development Toolkit (FDT) that we have been using to flash this chip.

smile Renesas does provide a freeware utility to flash these chips called the UART Flash Memory Programming Utility or UFLA32R.

confuse UFLA has problems. I was able to Erase, Blank Check, and Program (I think), but not Verify (read back and confirm a good flash) using UFLA.

biggrin The M32R bootloader does not automatically Erase the flash when you first connect to it like the 7052 using FDT. In fact you can upload all the flash contents out of the chip via the wire harness.

bleh You need to know the boot loader password to do anything other than Erase the chip.

no So far I can not get one of those nice $20 USB-TTL cables to work with UFLA.

----------------------------------------------------------------------------
The details:

There are two ways to put the MCU into boot mode: 1) Power up the ECU with MOD0 pulled high to +5V or 2)Pull MOD0 high after power up and then momentarily apply reset. What happens in boot mode is that the MCU loads a boot loader program into RAM and executes it. In order to use the boot loader you need to know how to communicate with it.

The MCU manual has information on how to talk to the flash module inside the MCU. In other words it tells you how to write your own boot loader, but it does not give any information on how to talk to the default boot loader. Instead Renesas provides UFLA32R to talk to it for you. By FTD standards UFLA is pretty crude. However it does know how to flash the chips so if nothing else we can copy it and write a better one.  

There are some problems using UFLA. UFLA was designed to flash M32R MCUs not Denso ECUs with M32Rs inside them. So whats the difference? The signals are not connected directly to the MCU. They have to go through the ECU circuitry.

This becomes a problem because the first thing UFLA and the boot loader do out of Reset is auto negotiate a baud rate to talk at. UFLA starts at its highest baud rate sending a test byte to the boot loader and waits for a reply. If no valid reply is received then UFLA request the next lowest speed. You might have noticed FDT do the same thing if your USB cable connection was messed up. Eventually they agree on 115,200 baud. Once set you must reset the MCU if you wish to re-negotiate a different baud.

The problem is the ECU can apparently read much faster than it can write. The problem with the auto negotiating scheme is it only requires a single valid reply byte to lock in a baud rate. I get the feeling the ECU TXD output was not designed to handle so high a baud rate. The signal coming out of the ECU is very degraded at that speed and causes the PC to garble any packet more than 2 or 3 bytes in length. In other words the ECU can hear UFLA perfectly fine but UFLA only hears the ECU mumbling.

This does, apparently, allow you to erase, blank check, and program the ECU using UFLA because these are pretty much one way conversations from UFLA to the ECU. In programming for instance UFLA sends down a big long packet of data to flash and the boot loader replies with a single acknowledge char for each packet. However the Verify function requires having the ECU repeat back everything you just flashed into it which obviously doesn't work well. It gets to the third byte of the first packet then fails the verify

So the simple question is what if I wrote another program that started auto negotiating at a much lower speed. I'm betting if I sent 9600 has the first requested speed the ECU would agree to it. Or maybe there are some settings in the UFLA ini file that can reconfigure the autonegotiate behavior.

This autonegotiating is also why you can not use the USB serial TTL cables. Apparently the USB driver can not handle rapidly changing the baud rates because when using the USB cable the ECU fails to negotiate a speed. I can see on the scope that the USB is sending bytes but the ECU never recognizes a valid speed request and UFLA gives up and throws a comm error.

Again if we wrote our own version of UFLA, one that only used one baud rate or negotiated much slower, we could probably use the USB cables.

On the password situation. I was able to succesfully use UFLA because having cut open the ECU and uploaded all the ROM via the NBD port I had the password. Unfortunately what this means is that we may still need to cut open at least one example ECU for each model/year and upload the ROM if for no other reason than to get the password. On the other hand we might get lucky and the US K8 Busa uses the same password as the EU K8 Busa and we need simply upload it from the harness. If we are really lucky all the K8s; busa, gixxer, etc. use the same password.

One nice thing about the password though is that you will be able to lock people out of their ECU. So for instance if your a professional tuner and you tune a guys bike you can lock up his ECU so he can't share your tune with others. In fact you can turn off the NBD port so they wouldn't be able to download it even if they tore the ECU open. This makes these ECU much more promising for developing commercial maps or applications.

So ending on an up note I REFLASHED A K8 BUSA.

Still details to be worked out before it is ready for prime time. But it can be done. (And boy does it flash fast at 115k baud). I think in the end I will write a flash utility of my own so that I can upload ECUs as well as flash them. This also means that if we do another ECUeditor like program we will be able to incorporate the flash instead of running it as a second program.


 





__________________


Guru

Status: Offline
Posts: 741
Date:

well done RR.......smile

__________________


Guru

Status: Offline
Posts: 1247
Date:

Excellent!

__________________


Guru

Status: Offline
Posts: 1344
Date:

cool rr,we got a new turbo super street class bike waiting to be flashed..biggrin

__________________

09 busa.????? now what....still got what it takes.......!

I got what you need...!
www.poweredbyford.com

www.marc@poweredbyford.com

 



Senior Member

Status: Offline
Posts: 196
Date:


  ECU's are frightened of your name as they know you will KICK their butt!
  Way to go!

 Thanks for your efforts.

Mark

__________________


Guru

Status: Offline
Posts: 963
Date:

I've been able to successfully negotiate different baud rates from 9600 up to 115,200 with the boot loader in the K8 Busa ECU. I've also been able to pretty much figure out the protocol so I think I am going to go ahead and write my own flash utility for the ECUs.

I'm going to include an upload utility that will allow you to upload the ECUs if you have the correct password. Those of you with other bikes using an ECU with an M32R will be able to see if you can grab the code out of your unit without cutting it open, provided the password is universal.

Or you can sit there and try and guess the password. It is 96 bits so there are only 79,228,162,514,264,337,593,543,950,336 possibilities. Actually Denso used all ASCII characters for this one so that narrows it down.

__________________


Senior Member

Status: Offline
Posts: 196
Date:


  Hey RR,

 I have a US K8 1000 and if you would like me to test your upload utility I would be happy to give it a try. The only condition is I only have the one ECU and it is on my daily bike so, care must be taken to only do an upload at first. I can also provide general information about the bikes stock wiring as mine is bone stock at this time.

 On my 04 Busa I made my own flash unit and wired it by myself "with Petrik's instructions of course" and I have did several flashes. I also have been using Romraider to do most of the work.

 Thats my resume, my e-mail buddrinker59@yahoo.com


Mark


__________________


Guru

Status: Offline
Posts: 2338
Date:

RidgeRacer wrote:


On the password situation. I was able to succesfully use UFLA because having cut open the ECU and uploaded all the ROM via the NBD port I had the password. Unfortunately what this means is that we may still need to cut open at least one example ECU for each model/year and upload the ROM if for no other reason than to get the password. On the other hand we might get lucky and the US K8 Busa uses the same password as the EU K8 Busa and we need simply upload it from the harness. If we are really lucky all the K8s; busa, gixxer, etc. use the same password. 



Well done !!!

I remember reading this with cars and also I guess that this backdoor is the method christian and many of his colleagues are using when reading and flashing ecus.

I have one ecu on the desk and will be firing it up in a couple of weeks and one complete K9 bike (most likely) coming in a few weeks time so its time to prepare myself with proper tools for the attack.

Recall that renesas gives a lot of alternatives for M32R development kits, but what would be the recommended hardware for connecting to the bus, would I like to use the same as you (RR) just for simplicity ?




 



__________________

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

http://www.facebook.com/ecueditorcom



Guru

Status: Offline
Posts: 963
Date:

I'm a little confused by the meaning of

...hardware for connecting to the bus...,



Are you talking about the AUD like NBD port CN501 inside the ECU  (what I consider the physical "backdoor") or are you talking about the serial flash lines in the wire harness connectors?



__________________


Guru

Status: Offline
Posts: 2338
Date:

Oh - sorry, I am just getting into this so many things are wondering in my mind simultaneously. (really only today made my mind up to get a K9 so the motivation is getting there)

CN501 is what I was thinking of. I am not yet sure of the needed functionality required to:
1) Download the rom contents
2) Monitor the data area while running the ecu
Manual says its JTAG, not AUD so trying to figure what kind of hardware is needed.

I am thinking (instead of cutting the ecu open) to try firing it up with the bike emulator and then identifying harware ports using a debugger. Do you see this as a feasible approach based on what you have read the code so far ? (The biggest problem currently foreseeable in this approach is the potential need for a chipped security key before the ecu can be fired up - but its possible that the ROM ports will still be read.)

EDIT - the thing really puzzles me is that on the pcb there is 12 soldering points like in an AUD connector but in the manual for JTAG there is only 8 marked for an JTAG port.



-- Edited by PetriK at 16:39, 2009-02-21

__________________

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

http://www.facebook.com/ecueditorcom



Guru

Status: Offline
Posts: 2338
Date:

Oh, man - I am very slow today. The NBD is an AUD like interface. Thats very good - have not validated the protocol and hardware interface, but having briefly looked into the manual it looks very similiar to AUD.

Now looking for the physical spec for NBD and then try to validate if the protocol is the same - but as the port is named CN501 would guess that its very alike.

__________________

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

http://www.facebook.com/ecueditorcom



Guru

Status: Offline
Posts: 963
Date:

PetriK wrote:


Oh - sorry, I am just getting into this so many things are wondering in my mind simultaneously. (really only today made my mind up to get a K9 so the motivation is getting there)

CN501 is what I was thinking of. I am not yet sure of the needed functionality required to:
1) Download the rom contents
2) Monitor the data area while running the ecu
Manual says its JTAG, not AUD so trying to figure what kind of hardware is needed.

I am thinking (instead of cutting the ecu open) to try firing it up with the bike emulator and then identifying harware ports using a debugger. Do you see this as a feasible approach based on what you have read the code so far ? (The biggest problem currently foreseeable in this approach is the potential need for a chipped security key before the ecu can be fired up - but its possible that the ROM ports will still be read.)

EDIT - the thing really puzzles me is that on the pcb there is 12 soldering points like in an AUD connector but in the manual for JTAG there is only 8 marked for an JTAG port.



-- Edited by PetriK at 16:39, 2009-02-21





When I access it from the front with the password it is running a boot loader, not user code. To do what you want you will need to go through the CN501 as before...that method works rather well

analog / ports register scan

 



__________________


Guru

Status: Offline
Posts: 2338
Date:

Excellent - looks like you are well down the track too on this one already when identifying the ports ... shall be fun soon to look the actual code ... I still dont have ida up and running so no .idc:s yet.

If I recall correctly this is the chip that has a semi public domain usermode kernel made by openecu.org chaps which allows writing only pieces of the code at time making map changes possible while running the ecu.






__________________

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

http://www.facebook.com/ecueditorcom



Guru

Status: Offline
Posts: 2338
Date:

Only now looked into serial programming protocol a bit more in detail. It looks like you (RR) have hacked the renesas Serial Protocol D. Wanted to take a look into this just to figure out if erase/program a block command would be avail for speeding up the process.

With a couple of minutes search I was unable to find the latest spec, only a note that M16C, M32C and M32R share this same protocol. The M8C Tiny is said to be very alike, some notes about checksum being different.

I hope you find this M8C info useful for next versions of m32rr (it may not correlate 100% to m32r, but should be close enough to get an idea).

m8c_flash_programming.jpg





__________________

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

http://www.facebook.com/ecueditorcom



Guru

Status: Offline
Posts: 963
Date:

That is a great find.

I have to say though PetriK I am curious why you posted this in the public domain instead of emailing it to me or posting it in the private forum.

I thought we had an agreement. I send you my m32r flash program so you can be one of the first guys on the planet to flash his GenII Busa and in return we keep the details of flashing these ECUs between ourselves.

Apparently I didn't fully explain the details of the keep it to yourself plan.

I didn't send you my software so you could capture the protocol, research it, and then post the protocol details to the world.

Why would you do this?

__________________


Guru

Status: Offline
Posts: 2338
Date:


I think we need to share some degree of information with the world and not keep quiet all the time. As you can see the rest of the protocol is published on the non public part of this board. This board is degrading unless its actively used for information sharing too.

Your software has not much to do with this find, exept that it started the process. All this is more related to early study of ufla32rr and yesterdays discovery of FDT spec which lists M32R as protocol D. I have had all these documents on the hard drive since we started to discover the gen1 protocol so it was easy to put 1+1 together when starting to think about it.

Btw. and as a sidenote. Until yesterday I thought that you had a different proposal - something where you would let the busa owners flash for free, but I had proposed that it could be a licensed product too. Never got an answer to that. So far I dont know what your commercial model is. Until that is known and we can start make some progress I also need to look for alternative options for ECUeditor which will stay free. Right now the project is stalled partially because of fashing part being open.



__________________

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

http://www.facebook.com/ecueditorcom



Guru

Status: Offline
Posts: 1344
Date:

hey guys has anyone looked at  v.03 it looks awfully familiar??? reading the pdf file it has alot of features,including protocol d,unique flashing capibilites,row checksum,auto erase,programing locks...ect........smile

__________________

09 busa.????? now what....still got what it takes.......!

I got what you need...!
www.poweredbyford.com

www.marc@poweredbyford.com

 



Guru

Status: Offline
Posts: 1344
Date:

using v.03,it seems that the m16,m32c,and m32r share the same protocol d,it has login?wait for script,this command must be executed before the connect command
size id=7
id code=must be hexidecimal form to match the surplied parameter?is this what rr was talking about the password???

once it is setup,your workspace and project,you can use the basic simple interface programming mode...

you can,login,batch erase,auto disconnect,readback verify,request checksum,erase device before programming,and have a unique code programing mode in which it can have a start and stop that the user can program....this looks promising,but i have more homework to do....can anyone help???

 



__________________

09 busa.????? now what....still got what it takes.......!

I got what you need...!
www.poweredbyford.com

www.marc@poweredbyford.com

 



Guru

Status: Offline
Posts: 1344
Date:

i guess the next step is to load the 32920-15h10 .bin in ida pro and dissassembe it looking at the adress to see if i can find this password???

__________________

09 busa.????? now what....still got what it takes.......!

I got what you need...!
www.poweredbyford.com

www.marc@poweredbyford.com

 



Guru

Status: Offline
Posts: 1344
Date:

i have already set up a workspace and project,set baud rate and loaded a 15h10 file and tried to connect with the txd and rxd pins connected together to see what happens,no error or com issues???since the guys have already downloaded the file,do we even need to worry about the password?? 

__________________

09 busa.????? now what....still got what it takes.......!

I got what you need...!
www.poweredbyford.com

www.marc@poweredbyford.com

 



Guru

Status: Offline
Posts: 1344
Date:

the lock bit is when executing the BSET or BCLR instruction,and is cleared when BSET or BCLR  instruction finishes.
 
the lock instruction sets the lock bit,as well as performs an ordinary load operation.The unlock instruction is used to clear the lock bit.

the lock bit is located inside the cpu,and cannot be directly adressed for read or write by users.This bit controls granting of the bus control requested by devices other than the cpu.

when lock bit="0"
        control of the bus requested by devices other than the cpu is granted

when lock bit="1"
         control of the bus requested by devices othe than the cpu is denied
in the 32196 group,control of the bus may be requested by devices other than the cpu in the following two cases:

when dma transfer is requested by the internal dmac
when hreq# input is pulled low to request that the cpu be placed on hold state



__________________

09 busa.????? now what....still got what it takes.......!

I got what you need...!
www.poweredbyford.com

www.marc@poweredbyford.com

 



Guru

Status: Offline
Posts: 1344
Date:

h'0080 0000           interrupt vector register
h'0080 0002           use inhibited area
h'0080 0004 interrupt request mask register on +0 adress not used on +1 adress
h'0080 0006 sbi control register on +0 adress not used on +1 adress
h'0080 0056 iramwrcr on +0 adress and can 1 error(ican1ercr)on +1 adress
so somewhere in the beginning adress starting with h'0080 000 we should find the "password" or hexidecimal code???                   
                        

__________________

09 busa.????? now what....still got what it takes.......!

I got what you need...!
www.poweredbyford.com

www.marc@poweredbyford.com

 



Guru

Status: Offline
Posts: 1344
Date:

am i going in the right direction?

__________________

09 busa.????? now what....still got what it takes.......!

I got what you need...!
www.poweredbyford.com

www.marc@poweredbyford.com

 



Veteran Member

Status: Offline
Posts: 98
Date:

stocker wrote:

i guess the next step is to load the 32920-15h10 .bin in ida pro and dissassembe it looking at the adress to see if i can find this password???




Yes , or you take a look into the sourcecode from the EE2.0 there you can also see the passwort.



__________________


Guru

Status: Offline
Posts: 1344
Date:

Boerd wrote:

stocker wrote:

i guess the next step is to load the 32920-15h10 .bin in ida pro and dissassembe it looking at the adress to see if i can find this password???




Yes , or you take a look into the sourcecode from the EE2.0 there you can also see the passwort.



thanks boerd,i do not even own a newer bike,but now feel challenged to see if i can do it.......smile

 



__________________

09 busa.????? now what....still got what it takes.......!

I got what you need...!
www.poweredbyford.com

www.marc@poweredbyford.com

 



Guru

Status: Offline
Posts: 1344
Date:

i can't see any reason why i would need the password if the "complete" .bin with the correct starting adress has already been posted??   i do know that there is "different" starting adresses between the different programs.....

__________________

09 busa.????? now what....still got what it takes.......!

I got what you need...!
www.poweredbyford.com

www.marc@poweredbyford.com

 



Veteran Member

Status: Offline
Posts: 98
Date:

OK, I hope I have understood correctly,
you need the password for the bootloader to activate the ECU flashing,
unless you open the ECU and use the UFLA32R.

__________________


Guru

Status: Offline
Posts: 1344
Date:

Boerd wrote:

OK, I hope I have understood correctly,
you need the password for the bootloader to activate the ECU flashing,
unless you open the ECU and use the UFLA32R.



yes,i know that renesas does not support the ufla32r,but still has the documention still on their website,including the protocol....so i am looking for the hexidecimal password that is in the cpu to activate the ecu in boot mode.......

 



__________________

09 busa.????? now what....still got what it takes.......!

I got what you need...!
www.poweredbyford.com

www.marc@poweredbyford.com

 



Guru

Status: Offline
Posts: 1344
Date:

"Yes , or you take a look into the sourcecode from the EE2.0 there you can also see the passwort."

that would be a easy way,but i want to challenge myself into doing it the hard way...for my own personal satisifaction.....



__________________

09 busa.????? now what....still got what it takes.......!

I got what you need...!
www.poweredbyford.com

www.marc@poweredbyford.com

 



Guru

Status: Offline
Posts: 1344
Date:

I want to give it a try,i does not look like anyone other than rr,and petrik has given it a try,everyone sat back and waited for them to develop it,i want to try to help,and i am getting better at understanding it everyday.........smile



__________________

09 busa.????? now what....still got what it takes.......!

I got what you need...!
www.poweredbyford.com

www.marc@poweredbyford.com

 



Veteran Member

Status: Offline
Posts: 98
Date:

HI, if you want to go hard way,
look into the M32196PDF there are the addresses where are the password
convert the K8.bin with bin2hex open it with a text editor and you can see the password or invite the K8bin in IDApro and you have the password.


__________________


Guru

Status: Offline
Posts: 1344
Date:

" The internal flash memory has a virtual flash emulation function, allowing the internal RAM to be

superficially mapped into part of the internal flash memory. When combined with the internal Real-

Time Debugger (RTD) and the M32R familys common debug interface (Scalable Debug Interface or

SDI), this function makes the ROM table data tuning easy.

The internal RAM can be accessed for reading or rewriting data from an external device independently

of the M32R-FPU by using the Real-Time Debugger. The external device is communicated

using the Real-Time Debuggers exclusive clock-synchronous serial interface." DOES THIS MEAN WE COULD POSSIBLY TUNE IN REAL TIME???



__________________

09 busa.????? now what....still got what it takes.......!

I got what you need...!
www.poweredbyford.com

www.marc@poweredbyford.com

 



Guru

Status: Offline
Posts: 2338
Date:

yes it does, an ecu that has AUD connector in it you can flas a limited memory area in real time, but as fast flashing also takes only secons thats ok too.


__________________

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

http://www.facebook.com/ecueditorcom



Guru

Status: Offline
Posts: 1344
Date:

so has anyone tried to use ftd 4.03 to flash???we can still use bin2xml and write up some def's and use romraider........

__________________

09 busa.????? now what....still got what it takes.......!

I got what you need...!
www.poweredbyford.com

www.marc@poweredbyford.com

 



Member

Status: Offline
Posts: 14
Date:

"If the internal flash memory needs to be protected while using a general-purpose programming/erase tool, set
any ID in the flash memory protect ID verification area (H0000 0084 to H0000 008F)." (ends at 0093 for the 32176)


__________________
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