FORScan PCM reprogramming (as-built) RX-8 (+other Mazdas...)

[ste94pz]

Hi, I'm interested in the pcm as-built reprogramming on the RX-8, are there any news?

[JamieM]

Nope. Other than what's in my post. You can reprogram everything except PCM1-PCM9 (not with forscan but manual IDS commands using ELM327)

Of course you can do it with Mazda IDS and a VCM, or a cheaper Chinese copy e.g. VCX Nano or similar

[JamieM]

Well, I got access to a VCM clone (VCX Nano) and sniffed what Mazda IDS does, and I've solved my own problem. Can now write PCM1-9 with an ELM327.

Turns out I had the protocol exactly right, the ELM327 just wasn't sending the multiple frames of the CAN packet fast enough. There's no time to use the serial port and wait for responses, the RX-8 PCM seems to expect a very short delay between the frames otherwise it times out and ignores your request. So before sending a multi-frame CAN packet, just set:

Code: Select all

>AT CAF0      <--- auto formatting off
OK

>AT AT0       <--- disable adaptive timing (may not be necessary with ATR0)
OK

>AT ST01      <--- shortest timeout possible (may not be necessary with ATR0)
OK

>AT R0        <--- disable responses
OK

>10 82 3B00 4A4D5A53
>21 45313733363030
>22 313233343536FF
>23 FFFFFF2ABBBBBB
>24 BB030DBBBBBBBB
>25 BBBBBBBBBBBBBB
>26 BBBBBBBBBBBBBB
>27 BBBBBBBBBBBBBB
>28 BBBBBBBBBBBBBB
>29 BBBBBBBBBBBBBB
>2A FFFFFFFFFFFFFF
>2B FFFFFFFFFFFFFF
>2C FFFFFFFFFFFFFF
>2D FFFFFFFFFFFFFF
>2E FFFFFFFFFFFFFF
>2F FFFFFFFFFFFFFF
>20 FFFFFFFFFFFFFF
>21 FFFFFFFFFFFFFF
>22 FFDEFEFF300000

Then turn responses on again / return timing to normal afterwards. Seems to work with my ELM327 USB clone. Kind of a hack really, because we aren't even waiting for the 30000000000 confirmation from the PCM, nor checking the response at the end, just hammering the data out as fast as we can. But it works. We are kinda pushing the limits of the ELM here because it doesn't really support sending multi-frame CAN packets, only receiving, at least not in the version I have.

Of course since we turned off responses we don't see the PCMs response which would normally be:

Code: Select all

7F3B78

which isn't an error, but means "ok I got that, but I need some time to process / store it, so gimme a sec and I'll tell you when I'm done".

Then a short while later you get your 7B00 confirmation. We don't see this, however, reading the data back again with 2100 shows that it has changed. Hurrah!

[ChainSOV]

Hi JamieM,
I wanted to answer you in your rx8cc tool thread, but it seems I don't have the rights to do so
First I wanted to say thank you for your research and your tool, I now have a bit of hope that this can also be applied to my Mazda3 BK 1.6diesel, where the CC also seems to be deactivated in the PCM.

comparing my as built to a similar model where it was factory installed I saw a difference in IC module, which I was able to change in forscan, but it seems further changes are needed in PCM2 or PCM3.

Unfortunately Forscan can not edit PCM data, but you seem to have found a way.

It also seems that CC is in a different bit on Mazda3 though than on rx8.
both m3 PCM2 as built seem to have FF on position 9 and 10
3D0DA4FFFFFE
3DFFFFFFFF4B

I already checked that your script has a secret key parameter, so it would theoretically work for writing PCM Data on other Mazda models, if they need another access key.

Beside being usable for other models, it could also be used for other purposes, like backup and restore, or maybe some other options that can be uncovered by the community

it ideally needs further parameters like the line/position to change + new value or full as built string/file

[JamieM]

Thanks

I could have quite easily read/written the ABD from/to a file and allowed arbitrary changes, but I wanted to avoid the headache/possiblity of more going wrong and supporting people in that. A lot of the slower or poorer quality ELM327 clones for example can't actually read the whole VIN block without getting a "BUFFER FULL" error, so backups would be tricky. Basically in that situation you can only write it, so you have to be absolutely sure you're writing the correct thing. Hence I limited it to just the single byte required for cruise and it does it all automatically. Also didn't want to step on FORScan's toes

I see no reason why the same protocol wouldn't work on other similar age Mazdas, though as you've identified the data will be slightly different. Perhaps we can even compare the data from different models to find out what all the bits do. Almost the entire PCM section in an RX-8 is FFs, but I'd be willing to bet they re-used common bits from their ecu code across multiple cars. Here's what I know so far about the RX-8:

PCM Module
PCM 1 FFFF FFFF 0310
PCM 2 0DFF FFFF FF1B
PCM 3 FFFF FFFF FF0E
PCM 4 FFFF FFFF FF0F
PCM 5 FFFF FFFF FF10
PCM 6 FFFF FFFF FF11
PCM 7 FFFF FFFF FF12
PCM 8 FFFF FFFF FF13
PCM 9 FFFF FFFF FF14
7E0-01-01 3133 4895
7E0-02-01 3620
7E0-03-01 4631 62
7E0-04-01 301C

The red byte is cruise control. Well, the last bit of the byte is: FE (11111110) for cruise enabled and FF (11111111) for cruise disabled. 0 to enable, 1 to disable, probably because most flash chips default to 1's rather than 0's, so it's easier to leave everything as 1's i.e. FFs and only overwrite if necessary.

The light grey bytes are checksums for each line and can be ignored for comparison purposes - they are only used to verify data entry in IDS (and FORScan) and aren't actually sent over CAN to the car. If modifying the line you have to update the checksum if you're using IDS/FORScan. They are simply the modulo 256 (8-bit truncated) sum of each byte in the line, including the address, e.g.:

Code: Select all

7E0-01-01: 31 33 48 95

[0x07, 0xE0, 0x01, 0x01, 0x31, 0x33, 0x48]

0x07 + 0xE0 + 0x01 + 0x01 + 0x31 + 0x33 + 0x48 = 0x195

0x195 & 0xFF = 0x95

The "PCM" lines seem to have "addresses" equivalent to (0x10 + n) in hex for the purpose of this checksum calculation, where n is PCM<n> e.g. PCM5 is (0x10 + 0x05).

The green byte is I think the number of gears in ASCII - 0x36 is "6" in ASCII, as seen above for a 6-speed (231) RX-8. I've only seen the data for one 5-speed (192) RX-8, and they had 0x35 here i.e. "5" in ASCII. Not certain on this due to lack of evidence but it seems plausible.

I suspect the rest of the 7E0 lines are ASCII too, they look like it to me (I've taken off the checksum bytes from each line):

Code: Select all

7E0-01-01 3133 48
7E0-02-01 36
7E0-03-01 4631
7E0-04-01 30

Translates to:

Code: Select all

13H
6      <-- number of gears
F1
0

I suspect some of this is country codes or something along those lines, as they seem to be the main thing that varies between JDM, USDM, EUDM etc as-built data. Does it mean anything to anyone?

The data actually sent over CAN includes the VIN, PCM ABD section, some other unidentified data, and a (different) checksum over the whole lot, collectively known as the "VIN block". It looks like this (VIN altered for privacy):

>10 82 6100 4A4D5A53
>21 45313733363030
>22 313233343536FF
>23 FFFFFF2AFFFFFF
>24 FF030DFFFFFFFF
>25 FFFFFFFFFFFFFF
>26 FFFFFFFFFFFFFF
>27 FFFFFFFFFFFFFF
>28 FFFFFFFFFFFFFF
>29 FFFFFFFFFFFFFF
>2A FFFFFFFFFFFFFF
>2B FFFFFFFFFFFFFF
>2C FFFFFFFFFFFFFF
>2D FFFFFFFFFFFFFF
>2E FFFFFFFFFFFFFF
>2F FFFFFFFFFFFFFF
>20 FFFFFFFFFFFFFF
>21 FFFFFFFFFFFFFF
>22 FFDA00FF300000

Key:

Headers
Flow control, frame type, sequence number (0.5 or 1 byte) - not part of the data. See https://en.wikipedia.org/wiki/ISO_15765-2
Data length = 0x082 = 130 bytes (includes command and data, except padding, excludes flow control and itself. (1.5 byte)
Command = command to write to ECU (0x3B) or response of read (0x61), data ID = 00 = VIN Block (2 bytes)

Data
VIN = JMZSE173600123456 in ASCII (17 bytes)
Unknown data (5 bytes)
ABD = PCM1 to PCM9 without line checksums (45 bytes)
More unknown data (57 bytes)
checksum, see below (2 bytes)
FF30 (2 bytes)
padding (not part of the data, just fills the CAN frame up to 8 bytes)

The whole VIN block has a checksum near the end. It is calculated as a 16-bit (or "modulo 65536") sum over the entire VIN block, excluding the data length, command, and flow control bytes (so just the data stored on the car, not the CAN frame headers). Then the two checksum bytes are replaced with whatever number needs to be added to make the whole sum equal to 0.

For example:

(0x4A4D + 0x5A53 + 0x4531 + ... all the rest of the data ... + 0xFFFF + ???? + 0xFF30) & 0xFFFF = 0x0000

Adding up everything other than ???? gives us 0x372600. Solving this we get:

???? = 0x10000 - (0x372600 & 0xFFFF) = 0x10000 - 0x2600 = 0xDA00

To check, plugging 0xDA00 into the original formula gives us 0, as we expect.

This checksum must be correct or the PCM will throw a DTC P0601 - VIN block integrity check failed "internal memory check sum error" - and light up the Check Engine Light. Car will still start, but cruise won't work, and the code cannot be cleared (it just instantly comes back). Once the checksum is corrected the code will disappear and CEL goes out. As it's near the end of the block it is often missing when attempting to read it using slower / poorer quality ELM327 clones, so I had to figure out how it is calculated from scratch in order to write data without causing a CEL

For comparing to other cars, it would be useful to see your full ABD and also the result of sending the command "2100" using an ELM327 to the PCM (7E0) to get the full VIN block as well. If they are similar enough, you may be able to run rx8cc without ill effect and see if it works - I included the entire key repository from IDS so it might already have the secret key it needs to connect to other Mazdas (or it might even just be the same as the RX-8 key...). Don't do this without confirmation from me though, let me check your data first! If it is a different length or anything like that it'll probably fail (or at least get the checksum wrong and give you a CEL), as I hard-coded the offsets for RX-8s not expecting other cars to ever use it.

[ChainSOV]

thank you for describing in detail how it all works,
after checking with my source, it seems that his car doesn't have CC after all, so I had a wrong as built file.
But he has seat heating, rain sensor, sun sensor, xenon lights and possibly heated mirrors, so his config should differ in these parts.

So it may be that CC is in the same pcm bit as on rx8.
Will try to find new as-built-data, or may be I will be brave enough just to try your tool

I have not installed the steering wheel switches yet, should CC still light up in the dash as the car is turned on?

[JamieM]

I have not installed the steering wheel switches yet, should CC still light up in the dash as the car is turned on?

Nope, with no switches there is no way to turn it on and thus no way to check if it is working. Nothing will light up until you press the main cruise control "on/off" switch

[ChainSOV]

thanks for the info, I thought the dash cruise light will light up while the ignition self-test runs

[JamieM]

Nope. It might do if you put the dash in lamp test mode - not just ignition on - but this doesn't mean you have working cruise. All the lights will light up in the dash test mode regardless of if you have the feature or not.

I was reminded of another way to test it without the buttons the other day - you need to know which wire in your car is the wire that connects to the cruise buttons, then you can ground this wire, which simulates pressing the main cruise "on/off" button. On UK RX-8s it's the green/yellow wire in connector X-05 behind the glove box - obviously going to be different on other cars.

[ClockWorK]

I just wanted to post to say that all of this is great work.