new SSM1 Definitions

[borland667]

Hi, I have a classic Impreza year 97 imported from Japan that has the yellow SSM1 plug.

I have the serial cable working properly but I'm getting that there are no definitions for it.

How can I help to create the definitions?

This is the info I got when trying the engine module:
Rom ID 0b04690101
System Type Unknown (A3 01 13)

Thanks!

[Comer352L]

Hi Osvaldo,

please create a dump file of your ECU IDs:

1. connect your interface
2. start FreeSSM (but no CU dialog)
3. switch on ignition, Cruise Control and AC
4. press Ctrl+Alt+Return (at the same time, the release)

After a while (max. 30s) a file named "dump.dat" will appear in your home directory.
Please send me this file via email (see address in "About").
Don't worry, there is no critical private data (VIN or serial numbers etc.) in it.

I'll get back to you as soon as I find time for it.
Thanks for your patience !

[borland667]

Sent via email! Thanks!! Let me know how else I can help...

[boffo97]

Hi there.
I have a similar problem. The ECU is for a 1997 Subaru Outback JF1BG9 EJ25D Australia-DM.
This version of FreeSSM (Linux build) can connect via FTDi-rs232-USB module to the ECU using SSM1 protocol; it gets the ROM-I.D. , but then I get the error message that there are no definitions for this vehicle.
I have tried to edit the SSM1defs_Engine.xml file with Byte values from the old SelectMonitor.ini file which best match this ECU; and also using a terminal communications command program to send hex code directly to the ECU byte-by-byte to monitor the response.
From your, Comer352L, instructions above, the only output to the dat file was the ROM-ID and possibly the TCU. Those numbers being A2 01 13 and 77 BB CA .
If you could tell me where to enter byte addresses ? it would be much appreciated.
Cheers——

[L1800Turbo]

77 BB CA ist the ABS control unit, I can add this address with the right data into SSM1defs_ABS.xml the next days...

As the Rom-ID A2 01 13 doesn't start with a 7x, any change in the SSM1defs_Engine.xml don't make a difference, as the ECU uses in addition to the RomID flagbytes which define the available functions.
From my sight, I'm not aware of the support state of using flag bytes with the SSM1 interface. Comer352l will be able to answer this..

I can take care of ABS.

[Comer352L]

Ah yes, Ax 0x xx IDs...
I started working on it several times but never found the time to finish the work.

As L1800Turbo already mentioned, these ECUs are using flag bytes.
IIRC, the main problem is that the flag bytes are not received properly with some ECUs.
The ECU from borland667 (see above) is one of them.

Can you please create a dump file (as described above) to find out if the current code works with your ECU ?
And while you are at it, please create a debugging log (compile as debug, start software with "./freessm > debug.log").
Please send me the files directly via email (see "About" in the software).

[boffo97]

Thanks to you both, Comer352L and L1800Turbo, for responding. I have sent you the data via email. Please
let me know if there is something I can do to help ? My knowledge of programming is limited, BASH scripts and a bit Python. C++ make my eyes tumble, but I have been reading your code over the past couple of weeks tying to understand it, there is so much of it.
What I can do is try to get the relevant ROM addresses for the data required. One of the few programs that work is called "Hterm" , it can easily connect to the ECU and send and receive hex. Unfortunately, the Linux version doesn't work with custom baud rates very well, because the ftdi-rs232 driver is locked into the kernel. The Windows version has no problem with the 1953bps baud rate.
So far, for the A2 xx xx ROM-ID addresses that seem to have meaningful data start at "h01" to "h27".
The TCU: h57, hB0, hB1, hB8, hBF .

——Cheers, boffo

[Comer352L]

Hmm... I have not received anything yet ?!

The Linux driver for FTDI hardware (ftdi_sio) supports non-standard baud rates well, so I suspect Hterm is to blame.
Try e.g. CuteCom instead.

First step is to get the SSM1 ID request command working properly...
Are able to read the flag bytes manually ?

[boffo97]

Files were sent to the email address found in the credits window of FreeSSM, I couldn't find one on GitHub.
Alternatively, I have created a repository, the files can be found at : https://github.com/boffo97/SSM1-dump .

The Linux ftdi_sio driver seems to works fine with the Python-Serial or the C++ Serial modules. But terminal programs like "socat" will not work, even when using ispeed and ospeed.
It would seem FreeSSM(dev) can make a valid connection to the ECU, but then closes after getting the ROM-ID. It would be good if FreeSSM could keep the the port open and then be able to manually type in the hex code for the ROM addresses to be read.

With Hterm.exe in Windows it can connect to the ECU at 1953 baud rate. I can then send (in hex format) "00 46 48 49", to which the ECU will respond repeatedly (about 5-7 per second) with the ROM-ID. Also "00 46 48 50", or, "00 46 48 51" will give another set of numbers. Sending "12 00 00 00" or simply "12" will stop the data stream.
Sending "78 xx xx 00" ROM addresses will respond with a continues stream, without having to send stop bytes when changing address.

——Cheers boffo

[Comer352L]

Files were sent to the email address found in the credits window of FreeSSM, I couldn't find one on GitHub.

Nothing arrived.:(

Alternatively, I have created a repository, the files can be found at : https://github.com/boffo97/SSM1-dump .

Got it, thanks.

The Linux ftdi_sio driver seems to works fine with the Python-Serial or the C++ Serial modules. But terminal programs like "socat" will not work, even when using ispeed and ospeed.

Maybe these programs use glibc functions to access/configure the serial port and you are facing this bug.
FreeSSM doesn't use glibc. Instead, it uses the kernel API directly.
At kernel level, there are actually two methods to set non-standard baud rates:

1. BOTHER + c_ispeed/c_ospeed
2. ioctl TIOCSSERIAL with flag ASYNC_SPD_CUST

The 2nd method is deprecated now but still works with many drivers. It has the advantage of being able to predict the resulting baudrate exactly, taking baud_base value and divisior into account.
This all has a long history...

With Hterm.exe in Windows it can connect to the ECU at 1953 baud rate. I can then send (in hex format) "00 46 48 49", to which the ECU will respond repeatedly (about 5-7 per second) with the ROM-ID. Also "00 46 48 50", or, "00 46 48 51" will give another set of numbers.

That's the expected behavior. The 4th byte is the number of extra data = flag bytes.
It's been a long time, but IIRC controllers can behave differently if more extra data is requested than available...
FreeSSM currently requests 0x20=32 flag bytes (which corresponds to the number of flag bytes returned by the first SSM2 ECUs).

Also: at least with some controllers, a set address command must be issued before the 0x00 command.
Bytes 2 and 3 of the 0x00 command must then correspond to the address set before.
I don't remember the details, but the address should be 0x8000 (at least for engine controllers).

Older ECUs didn't care about about bytes 2-4. Very old ECUs even accepted 3 bytes only.

Can you please try the following command sequence:
78 80 00 00 (expected response: 80 00 xx)
00 80 00 00 (expected response: A2 01 14)
00 80 00 20 (expected response: A2 01 14 xx xx ...

[boffo97]

Computer bugs....hmm! , quite astounding how they can go on for decades.

at least with some controllers, a set address command must be issued before the 0x00 command.

That does seem how this ECU is behaving, a "78 xx xx 00" needs to be sent before the "00" commands work.

Here is the response from :
78 80 00 00 = 80 00 FF
78 00 80 00 = 00 80 FF
00 80 00 00 = A2 01 14
00 00 80 20 = A2 01 14
So, as expected.
On a side note, 00 46 48 50 = A2 01 14 F7 78 85 00 00 00 00 DC 00 F4 7F 40 00 80 00 .

I have cobbled together a simple Python(Linux) script that connects to the ECU through the ftdi-rs232 module. It has absolutely no problem communicating with and sending commands to the ECU at the 1953bps baud rate, I still have to do a bit of work to do on the reading the response side of things. So at least we know that the hardware is all good to go in Linux.
——Cheers boffo

[Comer352L]

Computer bugs....hmm! , quite astounding how they can go on for decades.

It's hard to fix, at least without breaking the existing API.
Keep in mind that glibc supports multiple OSes (not only Linux) and processor architectures, which all differ. And there is POSIX.

Maintaining APIs for decades is not trivial, especially when the hardware it was initially designed for changes much during that time...

at least with some controllers, a set address command must be issued before the 0x00 command.

That does seem how this ECU is behaving, a "78 xx xx 00" needs to be sent before the "00" commands work.

Does the requested address matter ?
With other words: does something like

78 12 34 00
00 45 46 50

work ?

Here is the response from :
78 80 00 00 = 80 00 FF
78 00 80 00 = 00 80 FF
00 80 00 00 = A2 01 14
00 00 80 20 = A2 01 14

What's the response to command 00 80 00 20 ? Don't send the xx 00 80 xx commands !

So, as expected.
On a side note, 00 46 48 50 = A2 01 14 F7 78 85 00 00 00 00 DC 00 F4 7F 40 00 80 00 .

Ok, so this ECU sends up to the max. number of flag bytes it supports, even if more bytes are requested.
So byte 4 = 0x20 very likely isn't the problem here.

[boffo97]

Does the requested address matter ?With other words: does something like 78 12 34 00 00 45 46 50 work ?
Yes ,it works. It gives out that long array quoted in the previous post.
What's the response to command 00 80 00 20 ?
A2 01 14

Something to bear in mind, is that in the 1990s Australia was about ten years behind the rest world when comes to OBD-ii and pollution standards. Some of the sensors that are present in the EU & US models are not fitted to this model. e.i. the barometer and manifold vacuum, only one O₂ sensor.

——Boffo

[Comer352L]

Ok, so this ECU insists on 00 46 48 xx as flag byte request.
We can't simply change the request, because this will break others.

I wonder if S****U was playing games with diagnostic tool manufacturers...

[Comer352L]

Unfortunately I don't have more time today and likely also tomorrow.
Meanwhile, you can try the following hack (rename *.txt to *.cpp and replace the original files in /src).

SSMP1base.cpp
SSMprotocol1.cpp

An additional message box will appear and (hopefully) display the flag bytes.

[L1800Turbo]

Ok, so this ECU insists on 00 46 48 xx as flag byte request.
We can't simply change the request, because this will break others.

I wonder if S****U was playing games with diagnostic tool manufacturers...

This made me wonder as I didn't see it in the original SSM code.. Unfortunately I never finished the Axxx data cards, but this is a snippet from the Impreza '96 cassette:

8B15				L8B15:
8B15 : 0F 		" "		sei
8B16 : CC FF FF 	"   "		ldd	#$FFFF
8B19 : DD D1 		"  "		std	ssm_rx_byte_0
8B1B : 97 D3 		"  "		staa	ssm_rx_byte_2
8B1D : B6 C2 A0 	"   "		ldaa	ssm_0x00
8B20 : 97 BD 		"  "		staa	ssm_tx_byte_0
8B22 : CC 80 00 	"   "		ldd	#$8000
8B25 : DD BE 		"  "		std	ssm_tx_byte_1
8B27 : D6 84 		"  "		ldab	romid[flagcmd]
8B29 : D7 C0 		"  "		stab	ssm_tx_byte_3	; die 0x17 ablegen

The Original SSM actually seems to use 00 80 00 17 for flag byte requests. I didn't analyze the Legacy '97 cassette so far, although I don't expect big differences...

[boffo97]

' An additional message box will appear and (hopefully) display the flag bytes.'

Yes, thanks.
The flagbytes are : 0A 52 21 02 01
Also another debug-dump, including log data from when using the gui buttons : https://github.com/boffo97/SSM1-dump/blob/main/debug-A20114-ecu_2021-04-29_14-45.log

I had a bit of trouble compiling the latest commits. Error messages about "Qscreen" in the files : About.cpp, FreeSSM.cpp.
Hacked the line : " #if QT_VERSION < 0x050000" to if qt version is less than 6.
That seamed to work, but I will have to see why QT can not find the screen module.

@L1800Turbo -- I didn't have time to check those addresses.
Do you have the original SSM diagnostic tool ?

Also, I notice that people blank out manufacturers names, is there something in the rules about not posting manufactures names on GitHUb ? Like "Don't mention the war" . ;-0

[L1800Turbo]

Yes, I have the original tools to find out details about the communication.
But the last progress where I spent time on this is 5-10 years ago :(

[Comer352L]

This made me wonder as I didn't see it in the original SSM code.. Unfortunately I never finished the Axxx data cards, but this is a snippet from the Impreza '96 cassette:

I can confirm that 00 80 00 xx is used for the last SSM1 ECU/TCUs. And IIRC, other values didn't work (at least with the models I had tested).
Sure, the command may have been changed, e.g. to prevent the old SSM1 from working with later models.
But what's really weird here is that 00 80 00 xx seems to be accepted as ID request without flag bytes, but 00 46 48 xx seems to be required as ID request with flag bytes.

The Original SSM actually seems to use 00 80 00 17 for flag byte requests. I didn't analyze the Legacy '97 cassette so far, although I don't expect big differences...

Yes, but I don't think byte 4 is the problem here, because 0x49, 0x50, 0x51 seem to work, too.

[Comer352L]

The flagbytes are : 0A 52 21 02 01
Also another debug-dump, including log data from when using the gui buttons : https://github.com/boffo97/SSM1-dump/blob/main/debug-A20114-ecu_2021-04-29_14-45.log

That's weird, because (according to what you have written above) the flag bytes should be F7 78 85 00 00 00 00 DC 00 F4 7F 40 00 80 00.
The log also doesn't show the modification of the 00 command, so the change to SSMP1base.cpp has not been applied properly.

I had a bit of trouble compiling the latest commits. Error messages about "Qscreen" in the files : About.cpp, FreeSSM.cpp.
Hacked the line : " #if QT_VERSION < 0x050000" to if qt version is less than 6.
That seamed to work, but I will have to see why QT can not find the screen module.

Something really went wrong, please restart from scratch.

[Comer352L]

@boffo97
Did you use a serial port terminal and entered the commands manually ?
Or did you use the mentioned Python script ?
Time/timing//delays may be relevant !

According to one of my testing protocols, a 1999 2.5 Legacy TCU for example sends its' 3 byte ID permanently after it has received the 00 80 00 00 command.
If you have read just the first reply to the following 00 80 00 20 command, you might actually have read the response to the previous command.
ECUs require some time to switch the responses to the next command. And The response to 00 xx xx 20 is a large one, which might take more time.
Something like that ?

[Comer352L]

@boffo97
Hmmm...
In your first message you said, the ID of your controller is A2 01 13. Later you say it's A2 01 14.
Did you test different controllers ?

[boffo97]

">In your first message you said, the ID of your controller is A2 01 13. Later you say it's A2 01 14"

Yes, sorry about the confusion. A2 01 14 is the ECU that I have been running the tests on, the 1997 Outback.
A2 01 13 is the ECU for my son's 1994 Legacy BG GT-B twin turbo JDM, though it has gone through several engine changes and modification, nor is it the original ECU.

">Did you use a serial port terminal and entered the commands manually ?
Or did you use the mentioned Python script ?"

I used both Hterm.exe in Windows10, and use Python scripts in Linux with ftdi-rs232 usb-serial modules. Both return the same results. Other programs that sort of work are JECScan.exe and SelectMonitor.exe .
Here is a link to the very basic Python scripts: https://github.com/boffo97/Python . No where near the standard of your coding LOL!
One is for Tx and one for Rx. The reason for this is because I haven't been able to get Tx and Rx to work from the one script. But this also means a have to use two ftdi-rs232 modules on separate USB ports.
So basically, I send a read command and then the ECU responds continually until it receives a stop command.

On the compiling issue, I have re-done a complete git clone and also updated all the QT5 stuff on two computers; one is a desktop and the other is the laptop that is used to connect to the ECU. Both have the same problem.

When I can get a chance, I will retry your suggestions.

BTW, this is great work you are doing . I'm surpised that after all these years you are still active on this project, most give up after a couple.

——Cheers Boffo

[Comer352L]

I had a bit of trouble compiling the latest commits. Error messages about "Qscreen" in the files : About.cpp, FreeSSM.cpp.
Hacked the line : " #if QT_VERSION < 0x050000" to if qt version is less than 6.
That seamed to work, but I will have to see why QT can not find the screen module.

Fixed now.
QObject::screen() was not available before Qt 5.14.

[boffo97]

Fixed now.

Yes, thanks, Comer352L, it has done the trick. 👍
My system (XUbuntu 18.04.5) is using QT 5.9.. For it to work, I also updated the file "About.cpp" line 105 : #if QT_VERSION < 0x050000 to #if QT_VERSION < 0x051400.
Tested using XUbuntu 21.10(daily build), which installed QT 5.15.2, it has no problem compiing . 👍

Cheers.
——Boffo

[Comer352L]

My system (XUbuntu 18.04.5) is using QT 5.9.. For it to work, I also updated the file "About.cpp" line 105 : #if QT_VERSION < 0x050000 to #if QT_VERSION < 0x051400. Tested using XUbuntu 21.10(daily build), which installed QT 5.15.2, it has no problem compiing . 👍

Urgh... that one slipped through my thingers, thanks ! Qt 5.9 is really old !

[arthurlozano]

Hi, I'm having a similar problem, I compiled the master, but can't connect.

My Rom ID is A3 01 11.

Is there any news about this? Is there something I can do to help supporting these ECUs?