juanjux

I'm interested in the Europe Vs USA AFR tables in the ECU, could someone post them there (both)?

seikx8

There is progress, but slow. Currently I'm waiting to purchase the J2534 device as I am tight in budget at the moment. Otherwise, I have learned a lot about how the module is programed and such.

To lets you in some details, the Mazda Module Programming software seem to have a function for you to read the Flash from the PCM and check to see if the PCM is empty by validating if all data is Zero/FF (depending on the EEPROM each PCM use). In the application there are .DLL files which have functions interfacing with the Vehicle and reading/writing Flash images, etc. By default, it will auto check the HW and look in DB then connect to internet to get the latest info, if found you will be prompt whether you want to download & reflash with the new version.

However, there is option that would allow you to manually select a module flash File to upload to the PCM. There are options that set to prevent user from uploading the wrong flash file to the PCM but they can be turn off and bypass. Since I do not have the J2534, I cannot verify how that will work in the UI yet.

Regarding the flash image itself, I still have not figure out the checksum yet because there are missing data and I'm trying to locate and study the SBL (Secondary BootLoader) segment of the codes; these codes are upload/load from a protected region on he ROM to the RAM then run so that the reading/write process may occurs via communication with the a remote application such as the Mazda Module Programming Software.

As for the disassembly, I have about 350+ functions/subroutines identified and some jump/branch to address below 0x4000 which I currently have no access to so I can't verify the codes purpose.

And I was sick today, so I took a day off to rest. Still having a light headache at the moment

theboy

RE is visiting singapore and they say they can by pass the speed-cut. well?

Aseras

zoom talked to drewtech and they are going to offer a mongoose with a powersupply for flashing soon. that's the perfect tool. I'm waiting for it.

seikx8

To continue the saga,

if anyone want to pursue other alternative is to use the SCI port (Serial Communication Interface), there are source in japan that have those board to allow you to flash the ECU and here is the link for example if you understand Japanese (or to babefish translated): http://60.43.208.97/1/CPU-SH.htm

I've also read through many document from Renesas, the board can be reprogram directly via the SCI port (now I have understood how it works). The site also have the Flash Development Kit that you can download. Problem is, I have no spare ECU to play around with; because if you put the ECU into the wrong mode (boot mode) the entire flash will auto erase. This is the cheapest option you will find by making a very simple circuit to interface with the SCI that probably cost in the 2 digit figure.

And the cheapest J2534 device I found is McS1 from EEPod costing $475.

zoom44

have you had a chance to look at 2006 flashes yet?

zoom44

forgot to post the new flash levels here

Year Transmission/(Emission Type)/New PCM Calibration/Part Number/File Name
2004 A/T (All) N3Z1-18-881U SW-N3Z1EU000
2004 M/T (All) N3Z2-18-881T SW-N3Z2ET000
2005 A/T (Fed) N3ZA-18-881H SW-N3ZAEH000
2005 M/T (Fed) N3ZB-18-881G SW-N3ZBEG000
2005 A/T (Cal) N3ZC-18-881H SW-N3ZCEH000
2005 M/T (Cal) N3ZD-18-881G SW-N3ZDEG000
2006 A/T (Fed) N3M6-18-881F SW-N3M6EF000
2006 M/T (Fed) N3M5-18-881F SW-N3M5EF000
2006 A/T (Cal) N3M2-18-881F SW-N3M2EF000
2006 M/T (Cal) N3M1-18-881F SW-N3M1EF000

seikx8

I haven't have a chance to take a look on all the 2006 files to make any comparison. Between S & T, there are only 4 cells change look like for Throttle <= 5%.

Here are more patterns I've noticed:

The SBL block are the first 0x1800 bytes (these code are written to RAM and execute to do the reflash). If you break the flash image by taking out the SBL block and offset the contents by 0x2000, the image fit perfectly in the 512k space. There rest are to be write in the EPROM starting at 0x2000, indicates by the last 4 bytes in the image. The internal checksum information is locate at 0x7FB80 - 0x7FB8C:

0x7FB80 - Starting address: 0x2000
0x7FB84 - Block size/length: 0x7DAFF
0x7FB88 - Checksum

0x7FFF4 - Checksum
0x7FFF8 - Address of Main Entry Point: 0xd204, 0xd494, 0xd49c (differ by model year)
0x7FFFC - Flashable rom area starting address/FlashID: 0x2000

seikx8

More finding!

The checksum algorithm use similar technique as the one use by Subaru & Mitsubishi. You have a record to indicate the location for the checksum and a checksum value. It use this information to calculate the 32bit checksum by adding all double word (4byte) together from the range of address specified, that calculated sum value then added to the checksum value and compared it to the magic digit 0x5AA5A55A. There is also a second function which calculate using a different algorithm which use it to compare with 0xA55A5AA5. So in theory you cannot disable the check sum by giving it a 0 0 0x5AA5A55A for the first function, but will fail when the second one run when comparing with 0xA55A5AA5. Very clever idea indeed.

One down, one to go.

QBallz

Sounds like your making good progress!

seikx8

Ok after careful checking, the checksum algorithm is the exact same as Saburu: http://wiki.openecu.org/index.php?ti...ksum_Algorithm

There are two checksum function that have almost the same codes. I believe one run at start up, while the other one is scheduled as a task and wait for a flag (where this flag is set in an interval), if this flag is set, the codes will execute to validate the checksum.

I'm starting to get into the OS level and have more understanding on how it runs. The hard part is still figuring out the last checksum and the rest of the I/O so that the map value reference may be identify to belong to Fuels/Ignition/MOPs, etc. I would I got about 50% thru the codes already.

seikx8

Here is another teaser,

Within the rom there are information that have the following patterns:

2D scaling lookup table definition (aka: 3D map)
------------------------------------------------------------
2 bytes hold the column/X size
2 bytes hold row/Y size
4 bytes hold the starting address of the column/X scaling value
4 bytes hold the starting address of row/X scaling value
4 bytes hold the starting address of the cell values
? bytes hold some other info

1D scaling lookup table definition (aka: 2D map)
------------------------------------------------------------
2 bytes hold the table size
2 bytes hold some info
4 bytes hold the starting address of the scaling value
4 bytes hold the starting address of the table cell values
? bytes hold some other info

No more guessing with map location.

To be continue . .

seikx8

For better or worst, in order to get back to business, I just shell out $585 to buy the J2534 device, hopefully it will arrive one day so I can verify which calibration level my car had before taking it in for the recall service; anyone want to contribute and split the cost?

I have about 90+% codes dissambled and manage to mark segment belonging to hardward initialiation as well identified the OS routines: tasks scheduling, Interrupe, etc. Next step is to open the ECU and trace the pins layout to in order to corresponse to the I/O ports; this will give us the ability to identify the functions of each map.

In the contrary to the last checksum, I do have some hunt on what algorithm it use but need more verification. However, if that fail, we can always disable the checksum checking by disabled the codes in the checksum algorithm. Because the check use certain information of the codes that I have no access on.

These are the things I have been doing:

I was able to grab the bootloader codes off of the STI ROM with the sh7055 ecu from openecu.org, then pieced it to the image flash we had, then put it in the sh7055 ECU simulator. Woola, I got a complete functioning application and were able to verify many things. However because the bootloader is different then our, so I would expect some differences in the last checksum value, as it is looking at address 0x1000 that is in the bootloader area.

With all these knowledge, I'm sure some of you will find some values and pursuit your own need; just the lack of funding and time is the only thing that keep most us back *hint* *hint*

Red Devil

I've been following this thread closely, but don't really know anything about this subject to contribute.

That said, if you are close to being able to re-write the stock PCM and are looking for funding from forum members, I would suggest you start a separate thread and make a proposal to what you are doing, and what anyone that would invest money would get in return.

Are you going to put together a Do It Yourself?

Are you going to sell the software needed?

etc...

seikx8

After a few hours lastnight, I was able to verify half of the second checksum algorithm is verified. Here how the psuedo code look like:

for (x=0,y=0x2000, hiSum = 0, loSum = 0; y < 0x7FB80; x++, y += 2) {
W = Read word @ address Y
Q = W / ((x % 256)+1)
R = W % ((x % 256)+1)
HiSum += Q
LoSum += R
}

From 0x7FB80 to 0x80000 area, I have not able to verify yet and what it does with the value caculate because I mis-debug the jump so I will have to continue where I left off next time when I have time.

seikx8

I'm getting close, just have to wait until I get my J2534 device I will be able to do some testing. Once the checksum are figured out, I'll first look for code to modify a few setting where I can verify such as FAN on/off, Rev limitter, etc.

As for funding or making the application for sale, I have not think about that yet. Maybe I can develop a software to benefits the forum members by volunteer donation and contribute to the rxclub.com as a fund raising. Anyway, like you said that will be discuss in another thread as we are still in the development phase.

I will publish my research so that all forum member will benefits and there will be DIY instructions, etc. However, there are a certain things that will be keep secret as to protect future potential business interest and the like. Such as if a tune map is to be made available by a professional tunner, they will be protected by some secret way to prevent map from sharing, etc.

Just brainstorming, so don't quote this: if I have the software that would sale for like $100 a pop with a lifetime update and If I would able to get about 200 member to buy the software minus some % contribution back to rx8club.com, hmm that isn't a bad idea at all

merchgod

I'm from the Subaru world and have been working on definitions for Enginuity, which is open source tuning software ( www.enginuity.org ). Can anybody send me the roms that have been acquired so far for the RX-8? The map structure sounds almost identical to the 32bit Subaru ecus. Perhaps I can come up with something.

alnielsen

iTrader: (4)

Removing the roms would be difficult. Cobb has allready said that the ecu is similar to the Subaru's and are working on a product.

merchgod

From these posts, it seems that someone has got a hold of the image(s) somehow. That's what I'm looking for, regardless if there is a current method to extract the rom for end users, as there may be one in the future. I figured I'd take a look at it and perhaps create some definitions so the tables could be viewed in Enginuity.

seikx8

My pc was out of commission these past few days and I just recently build a new one and got it running but still have lots of software missing, especially the VS 2005 and some other utilities that I use to analyze the rom image.

Anyway, there are some bad and good news. The bad news is that, it will not be easy to trick the Mazda ECU Programming software to re-flash rom. But it can be done. The good new is that my J2534 device had arrived and I was able to pull my calibration level from my car which is currently at level M and was able to read the VIN info too. I'll be scheduling the recall this weekend and after that I will be able to do more testing.

I've also been looking at the 2006 ECU files and have wrote some codes to auto extract the map definition. But I'm mostly focus on the 2004 flash, so If anyone interest in digging on other year model I can provide the .xml for those file that is compatible with the open source ECU rom editor to view and edit the map. I've also been writing an application to modify the flash directly so that the file may be feed to the Mazda Programming Software to do the reflash, this is the easiest and quickest solution without having to rewrite the re-flashing software. Currently the total cost of the items that you need might not worth the efforts, but who know.

And yes, the Hardware is pretty much identical to the STI. The only different is the OS and wiring. And where did we get the rom image? well a subscription access to mazdatechinfo.com of course. Currently there is no known method available to any end user the extract the image, at least not to the open public.

For the the fun of it, if anyone really want to contribute, you can open your ECU and start tracing those wire such as ignition & fuel injectors. They will lead to one of the IO port pin at the ECU. I would recommend a magnifying glass

QBallz

I can give you a copy of VS2k5

seikx8

Thanks, QBallz.

I do have a copy. It's just that I have sucked into the Window Vista Beta Testing and need to figure out what is the best option to install all the software. Currently I'm looking into running other software in a virtual machine environment so I that later when I need to rebuild the pc again (whenever the final version of Vista is out), I do not have to reinstall everything. Best of both world I guess

And it's hard to keep up with technology these days.

SomeGuy_sg

Sweet stuff goin's on here
Hope that you crack that puppy open soon

seikx8

Got a few things done over the week. The attached is the latest Flash Edit. The SW-N3Z2ET000.xml is the map definition with the multiplier/constant added.

Please note it's not complete and only have these features:
- new .xml format structure with added support for coefficient/constant (multiplier/addition)
- checksum correction support
- allow you to save .phf file as well as modified .xml
- map definition is in a tree view (right click for sub-menu)

The map data value look much better now with the scaling factor applied.

And the following are the updated on how the map definition are represented and lookup:

2D scaling lookup table definition (aka: 3D map)
------------------------------------------------------------
2 bytes hold the column/X size
2 bytes hold row/Y size
4 bytes hold the starting address of the column/X scaling value
4 bytes hold the starting address of row/X scaling value
4 bytes hold the starting address of the cell values
1 byte function flag 0/4/8/C define data type
3 ?? alignement bytes
4 bytes float multiplier
4 bytes float constant


1D scaling lookup table definition (aka: 2D map)
------------------------------------------------------------
2 bytes hold the table size
1 byte function flag 0/4/8/C define data type
1 ?? alignement bytes
4 bytes hold the starting address of the scaling value
4 bytes hold the starting address of the table cell values
/* follow by optional 8 bytes for map that required scaling */
4 bytes float multiplier
4 bytes float constant

Because it use fmac (float multiply and accumulate) instruction, multiplier & constant always existed as a pair.
n = x * multiplier + constant

The 1 byte function is an offset to the interpolation function address (in multiple of 4) contains by an array.

There are 4 simple calculation function: 4-byte float, byte, 2 byte word, single-byte float. And 5 complex functions to do 2 dimension (4 points) interpolation.

Thanks merchgod for pointing out the multiplier/addion bytes that are exactly similar to the Subarus/Mitsubishi rom.

[Edit]
The previous file upload had a bug where 2/4 bytes data are modified as 1 byte data. This latest upload fixed the problem.

Aseras

I wish i could help more. I'm swamped at work. I do however have a msdn universal sub so let me see if there's a vista compatible VS beta in it