RomRaider

I'm looking for a little help communicating my with Subaru ECU. The ECU is question is from a 2006 WRX Turbo 5MT, although I don't think it matters in this case.

The gist of the project is that I am building an Arduino based SSM to CanBus convertor. There are quite a few examples of these floating around the internet, but I've yet to find one that accomplishes everything I need it to do.

The issue I'm running into is making block reads using the 0xA0 command as outlined here:

http://www.romraider.com/RomRaider/SsmProtocol

Making single or even multiple address reads using the 0xA8 command are successful every time, but the 0xA0 commands always result in a response of 255 for every value. it feels like maybe the addressing offset is different for block reads versus single address reads. I've looked through dozens of forums and GitHub threads on Arduino SSM communications, and I've yet to find anyone actually using block reads. I turned on verbose logging with RomRaider, and it appears that all of the calls coming out of it are multi address reads as well.

As example, if I issue the command to read my coolant temp at address 0x08 via

0x80 Header
0x10 to ECU
0xF0 from diagnostic tool
0x05 5 byte payload
0xA8 address read
0x00 single response
0x00 address byte 1
0x00 address byte 2
0x08 address byte 3
0x53 checksum

I get the response

0x80 header
0xF0 to diagnostics tool
0x10 from ECU
0x02 2 bytes payload
0xE8 I have no idea what the 5th byte is for, but it is consistent for response to 0xA8
0x47 converted to decimal is 71. 71-40 = 31C, which is about ambient in my garage at the moment and matches RomRaider display
0xB1 checksum

However if I try to read the same data via a block read

0x80 header
0x10 to ECU
0xF0 from diagnostics tool
0x06 6 byte payload
0xA0 block read
0x00 single read
0x00 address byte 1
0x00 address byte 2
0x08 address byte 3
0x01 read 2 byte (1-1)
0x2F checksum

I get the response from the ECU

0x80 header
0xF0 to diagnostics tool
0x10 from ECU
0x03 3 byte payload
0xE0 i have no idea what the 5th byte is for but it is consistent for response to 0xA0
0x255 i expected this to be 0x47 (or close to it)
0x255 9th byte is for AF correction, I would have expected 0 when the car is turned off
0x61 checksum


If I were to ask the ECU to read 128 bytes starting at 0x00, it would return me 128 values at 255 each.

I'm wondering if anyone here has any insight to what I might need to change to get the ECU to send me the addresses I think i want. if there is a trick to getting RomRaider to make a block read so I can how it does in verbose logging, that would be great too.

Thanks

A0 block read command returns the content of the ROM or RAM addressed if the ecu software permits to read this area.
You may find area examples here

viewtopic.php?f=32&t=8513

Denso MY06 you have mentioned allows those data to be read:

Denso 32 bit SH7058 calibration ROM start 0C0000 length 040000(not all area will be read)
Denso 32 bit SH7058 RAM start FF0000 length 00C000 (not all area will be read)

Restricted area will be read as 0xFF


A8 byte read returns SSM enumerated predefined parameters \ values.

In your particular development you may listen to ecu CAN message 0x600 and get byte 3 as Coolant value.
No SSM k-line connection is needed get Coolant value.

Thanks for the reply, looks like there is some good information there to help me.

As far as just reading the coolant, that is a test, but I'm looking to read a fair amount of information. I'm building a completely digital dash, so I'm reading about 25 values. A block read would help speed up my communications and generate less lag on the display. I'll take a look at the utility and the addresses he listed, thanks for pointing me there, not sure why I didn't find that thread with my searching, but it looks like a similar goal to mine.

To speed data readings up to 4 times you may use fast polling.
This method makes a list of data requested and set a condition to repeat the response forever up to a new scanner request ( the first new k-line request will obviously fail due to collision).

I am considering using fast polling, still doing some experimenting with using fast polling for all data, versus using multiple reads and getting stuff I need fast like tachometer, boost, and speedometer more frequently than things that move slow like fuel, coolant, odometer etc. I may go with a combination where I read the fast stuff continuously, then interrupt it every 30 seconds or so to get the slow data.

Thanks for the tip.

There's quite a bit of info in the CAN messages.