FreeDIACOM ? (long)

[Chad Clendening]

I havn't done anything with the SBEC but I have been working on the dual
module setup, the 85-7 setup

Some if the things I have found:

The baud rate is variable, sometimes the 7812.5 , sometimes 976.  You can
tell it to switch between the 2.

The serial protocol for that allows a couple of things:
    1) you can send it several bytes which add together into an address.
The program will then jump to that address.  This can ONLY be done upon
power on.
    2) you send it an address ( one byte) and it sends you the value at
that addres.  Since the chip only has 0x40 to 0xFF designated as RAM you
can get anything you please out of ram.  The error codes are included in
that.  The error codes are stored in 8 bytes, 2 sets of 4 codes.  It
appears one set is used for power on codes the other is a cumulative set.

I havn't looked much at the serial for a while, there may be more than
this also

Chad

Oleg Gusev wrote:

> Hi,
>
>  i think i'm not the only one who is surprised by
>  annoyingly high price for ( IMHO ) simple software like DIACOM,
>  and the absence of the publicly available protocol
>  specifications. So i decided to write the specification and
>  reference implementation for Linux at least for communication
>  with Chrysler SBEC which i have.
>  As far as i understand my SBEC uses TTL level asynchronous,
>  half-duplex, 7812 baud, no parity, one stop bit link.
>  The scantool is supposed to send a one byte "function" code
>  followed by several "arguments", which would be acknowledged
>  by SBEC, and then SBEC would send some "return code(s)" for this
>  "function". The number of "arguments" depends on the "function".
>  For example,
>  1. "function" 0x10 requests stored error codes and doesn't
>      have any "arguments"
>  2. "function" 0x17 requests flushing of all stored
>      error codes ( also no "arguments" )
>  3. "function" 0x13 requests running built-in test, and
>      has one "argument" - the number of the test.
>  4. "function" 0x14 requests realtime sensor data, also
>      has one "argument" - which sensor data to query.
>  5. "function" 0x1a requests switch/relay data ( on/off ),
>      has one "argument" to identify the switch/relay.
>
>  Do other "functions" exist ? This question is open.
>  The available "functions", the "arguments" they accept, the
>  meaning/units of "return code" and the hardware link
>  protocol may depend on engine/year/etc., so to create a full list
>  of available options would take some effort from all interested :-)
>  I should try to write this list at least for my SBEC
>  ( 3.0 Mitsubishi engine, 1990 ) during this weekend, so
>  everybody can get a feeling how it looks like and where to look for.
>  The DIACOM owners can help a lot by feeding DIACOM (with the help of
>  the debugger) with the fake input from the SBEC at some "magic"
>  places, so the relation between "return code" and the sensor data
>  value in Volts/Degrees/Steps/Percent/etc could be obtained.
>  There seems to be a lot of DIACOM GM users around, and i'm pretty
>  surprised that the people having enough qualification and patience
>  to diassemble ECU PROMs have not written the realtime monitoring
>  stuff...
>
>  Best regards,
>               Oleg.
>
> --
> AlphaBIOS message:
> "You have selected to switch to a different operating system.
>  This computer will no longer be able to run Windows NT."