Members Login
Username 
 
Password 
    Remember Me  
Post Info TOPIC: Denso 7052 and getting started...


Guru

Status: Offline
Posts: 2338
Date:
Denso 7052 and getting started...


Denso sh7052 is a processor widely used in motorcycle ecus including e.g. SV1000, ZX-6, Hayabusa. Additionally it is used in some cars like EVO7.

The manufacturer of the processor is Renesas (former Hitachi) and 7052 is a SuperH (sh) processor.

The processor itself is 32bit and has a flashable memory over a serial line. It is a standard feature in that prosessor that the flash memory can be programmed in boot mode just using a simple RS232-TTL converter and a PC. There is various software packages available for this purpose, but maybe the best alternative is FDT (Flash Development Toolkit) from renesas.

Anyhow there is an issue to get the Flash contents out of the prosessor memory. So far what we have learned is the following:

- There is an AUD connector which allows debugging the device with Renesas debugger device e10a. This e10a can also be used to access the RAM memory area, but it seems to have blocked the access to read directly the flash ROM area. Anyway according to the specs and signalling it could be possible to access the Flash for reading.
- One could send to the ram memory a program called "user mode microkernel" which allows the user to download the flash memory contents in an user mode. There is a rumour that this could be done using the AUD connector.
- The processor can be hardwired to emulate a hitachi EPROM, i.e. 40 pin HN27C4096HG. This requires the xtal to be changed to 6Mhz and wiring the processor pins to an EPROM reader. Doable but not necessarily quarantee that the code versions would be the same for target ecu compared to which the code was loaded from.

So to be able to program any sh7052 we already know that serial programmer can be used for flashing, but what is missing is the information of how to read the contents of the flash memory.

Here you are also with a picture of how sh7052 links to other Renesas processors. Often the documentation and interfaces cover the whole family rather than one processor so here we can see what are the other 3rd generation alike processors.

renesas_prosessors.jpg

-- Edited by PetriK at 07:05, 2007-11-12

__________________

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

http://www.facebook.com/ecueditorcom



Veteran Member

Status: Offline
Posts: 80
Date:

In the ECU for my SV1000, there are 12 oblong pads on the cct board that provide connection for AUD. They're located in the centre of the bottom edge of the board, in an ideal spot for a notch. The pads are numbered 1 to 12 from right to left, and they connect to the 7052 as follows:

1. PVcc, and also to pin 106 (HRxD) via a 10k resistor
2. earth
3. AUDCK
4. AUDSYNC
5. AUDATA3
6. AUDATA2
7. AUDATA1
8. AUDATA0
9. pin 110 (SCK2), and also 10k resistor to earth
10. AUDMD
11. HTxD (pin 187), and also 10k resistor to earth
12. AUDRST

From the datasheet, only 8 lines are needed for AUD (apart from a common ground):
3. AUDCK for clocking in the addresses and clocking out the data
4. AUDSYNC (low to feed in an address, high to read out the data)
5..8 AUDATA (4 bits, address/command/data)
10. AUDMD (high for RAM monitor mode)
12. AUDRST (for resetting the AUD in the mode selected by AUDMD)

Supported commands are read/write, byte/word/longword. That's it.

The AUDCK clock input must not, it seems, exceed 25% of the operating frequency.
I guess that's either 10MHz or 2.5MHz?? On my ECU there's a 10MHz crystal, but I think the 7052 runs at 40MHz? So the AUDCK has to be less than a quarter of either 10 or 40MHz.

Addresses and data can only be written/read 4 bits at a time, and the AUD can flag errors and also flag whether it is ready or not ready to send data out.

I don't really want to spend the bucks on the renesas e10a ... I think all that's needed is some simple logic to control the RST/MD lines, toggle the SYNC line, provide a clock on the CK line, and send commands/addresses in 4-bit chunks, and read data in 4-bit chunks. Also it will need a few smarts to detect any error conditions and to detect when the AUD is ready to start sending out data.

Since when reading or writing, the address has to be specified as a full 32 bit address, I'm hoping that the AUD can read all memory: 0..3FFFF for the flash ROM, and FFFF8000..FFFFAFFF for the RAM. And I'm hoping that it can also write to the ROM as well. And I'm hoping that any software or hardware protection that might be enabled is bypassed.

Next job for me will be to build a cct to handle the comms and timing, fire a bunch of read commands at successive addresses, and read back (and store) whatever the AUD spits out. And then see if any of it makes sense. weirdface.gif

Cheers,
MarkW


__________________


Member

Status: Offline
Posts: 7
Date:

PetriK wrote:


Anyhow there is an issue to get the Flash contents out of the prosessor memory. So far what we have learned is the following:



Hello, I am new to this forum and probably can help with that.
In my job, I work with Hitachi H8/300 processors, been doing it for almost 10 years now. Reading out the FLASH memory from the serial interface is easy if its the same on the more modern H8 CPUs. You just have to write a custom bootloader program and instead of programming the FLASH you simply read the memory and pass it back through the serial port.

I you could provide me with an ECU/serial cable to test on, I can write up a windows program to read and write the FLASH. It's really not that hard to do for me.

-Jerry



__________________


Guru

Status: Offline
Posts: 2338
Date:

Would it really be possible to connect to the ECU without the bootloader to first erasing the full flash memory user area ? There is no user mode microkernel present in the ecu code - or we have not yet found one...

About the interface, its very simple, you can find instructions here:
http://www.activeboard.com/forum.spark?forumID=99460&p=3&topicID=14784871

Alternatively you could use the E8 (or E8a) to be the interface for you. If you work with H8 you most likely have access to one very easily.

Anyhow unfortunately sh7052 is FZTAT processor which does not allow debugging with E8 unline some newer processors.




__________________

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

http://www.facebook.com/ecueditorcom



Member

Status: Offline
Posts: 7
Date:

PetriK wrote:

Would it really be possible to connect to the ECU without the bootloader to first erasing the full flash memory user area ? There is no user mode microkernel present in the ecu code - or we have not yet found one...

About the interface, its very simple, you can find instructions here:
http://www.activeboard.com/forum.spark?forumID=99460&p=3&topicID=14784871

Alternatively you could use the E8 (or E8a) to be the interface for you. If you work with H8 you most likely have access to one very easily.

Anyhow unfortunately sh7052 is FZTAT processor which does not allow debugging with E8 unline some newer processors.



You do not need a user mode kernel, we are using boot mode. I think you are confused as to the difference between user mode and boot mode. In user mode programming, the programming code is preprogrammed into the flash as part of the user program. In boot mode, the flash part can be blank as the programming code is downloaded into the part at boot time through the serial port. You simply have to write a boot mode program that does not flash the part but instead reads the flash. It is quite simple to do. I could easily do this, but I do not have the ECU hardware to test it on. I am not going to use my one and only bikes ECU.

If you are willing to loan me a ECU, I should be able to make it work in a few days. It involves writing a bootloader for the renasas CPU, and writing a Windows program to download and interface to the bootloader. The bootloader can be written to do anything you want. Actually, I would only need an ECU for final testing, I could knock out the code ahead of time, or even just let you be the remote tester and tell me how it works. It'll take longer to develop going back and forth, but I have done this before so there should be few mistakes in my code. I just have to learn this processor and find a free C compiler for it.

-Jerry




__________________


Guru

Status: Offline
Posts: 2338
Date:

That really sounds excellent !!! I have always thought that you must erase the flash as part of the process if you enter to the boot mode. But based on what you say it sounds like there is a way around it smile.gif. Maybe its just FDT that forses the ERASE process to start - lets hope so.

I am sure there must be an ECU available somewhere for you if that is what it takes - but may take also time...  Where are you based, as on this board we are hackers from Australia to USA not to forget northern europe (Finland) where I am located ?

Meanwhile I would be most interested in to kick start this initiative you suggest. So if you e.g. use Visual Studio for programming environment I can set that up here in a few moments to test any code that has been written on the workbench. (I only have the older version of the ecu as a spare unit right now).

What is it that this you in addition to an ECU to start writing such a software ? Anything special like sample bootloader programs or memory/port mapping or what ? I think we have all that info already digged out somewhere...

Could you please start by explaining how such a program would work in detail ?

Is it something like below you are referring to but skipping the erase somehow ?

programmer.JPG





__________________

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

http://www.facebook.com/ecueditorcom



Member

Status: Offline
Posts: 7
Date:

Oh crap, I may have spoken too soon. I just read the detailed programming info in the hardware user manual and although the process is VERY similar to the H8's I am using right now, there is one big difference in the flowchart that the H8's I have worked with does not do. This processor has a IP protection step in that it completely erases the flash BEFORE transfering control to the user boot mode program you downloaded through the serial port.

I understand what your talking about now, you cannot enter boot mode and not loose the flash contents. I can do this on the older H8, but I see now on this one that is not possible. You would have to go the route you were thinking before, program the mapping tables through a user mode program instead. That would require a custom ECU program to be written that we could include the programming code into such that you could download and install the maps only without programming the whole thing. The big disadvantage is we would have to develop a whole ECU program, or come up with some ingenious programming that overrides the original ECU program's startup code, does a jump, checks to see if we should be downloading maps, and if not, jump back into the main unmodified ECU program. That could be alot of nasty work, not only that, we would have to readout a ECU's program though the debug header as you have done first for evey supported ECU.

I wonder how different the race 'kit' ECUs are to the stock ones. I know these download map offets by serial port so some sort of flash writing program exists already in these 'kit' ECUs. Maybe the program already exists on these versions.

-Jerry


__________________
Don


Veteran Member

Status: Offline
Posts: 41
Date:

Jerry,
I downloaded the code from a 2006 Kawasaki ZX6RR Kit Racing ECU and sent it to RidgrRacer. After a very quick evaluation, it looked like the data was stored in a seperate flash memory chip. I still have to dig out the rest of the potting to confirm.
Let me know if you need any additional information.

__________________
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