Snoop Simple Serial Protocol (S3P)
Introduction
This protocol is provided as an example of how you can communicate with an embedded system using a stream interface such as RS232 or TCP/IP. It supports simple memory access commands to allow OpenECU Calibrator to update Watch and Memory windows.
The source code is included for both the protocol plug-in and hardware interface plug-ins so that developers can extend or modify the behaviour as required. See also the Developer help.
An example C-language program that compiles and runs under Linux is also included, which implements S3P. See Examples\snoop_linux_s3p in the program folder.
This complements the CAN packet-based protocols (CCP, UDS) that are typically used in OpenECU Calibrator to communicate with automotive ECUs. However, those protocols can of course be implemented in non-automotive systems too.
Datagram structure
| 0 | Protocol ID magic value indicating start of datagram: 0xA0: S3P MSB-first data, no packet checksum 0xA1: S3P LSB-first data, no packet checksum 0xA2: S3P MSB-first data, with packet checksum 0xA3: S3P LSB-first data, with packet checksum 0xA4-0xAE: reserved for future |
| 1 | Recipient node ID (for multiple ECUs on one bus e.g. RS485) 0x00: default for single ECU (host/server) 0x80: default for tool (client) 0xFF: reserved for broadcast to all nodes |
| 2 | Sending node ID, complement to recipient node ID, i.e. 0x80: default for tool (client) 0x00: default for single ECU (host/server) |
| 3 | Command counter: Tool (client) sends new value with each request; ECU (host/server) echoes value in response. (This allows the tool to ignore unexpected delayed responses to earlier commands.) |
| 4 | Payload length (L) in bytes, starting with next byte, excludes checksum |
| 5..(5+L-1) | Payload bytes (command-specific) |
| (5+L) | If checksum in use, checksum over all previous bytes: 1. Start with checksum C=0 2. For each new byte B, C -> (C + (C >> 4) + (B ^ 0x5C)) & 0xFF This is intended to be simple to compute for very low-end microprocessors, but with some resilience to inadvertently inserted zeroes or multiple bit errors. |
Status/Error Response Codes
| S3P_OK = 0 | No error, command completed OK. |
| S3P_GENERAL_ERROR = 1 | General error. |
| S3P_UNSUPPORTED_PROTOCOL = 2 | E.g. tool requested MSB-first order but ECU only supports LSB-first order. |
Commands
Ping
Request message:
| 0 | 0x01 = S3P_PING_REQUEST |
| 1 | Flag bits: 0: 1=ECU should now consider calibrations synchronised (event, 0 does not imply opposite) 1: 1=ECU should now consider calibrations unsynchronised 2..7: Reserved |
Respone message:
| 0 | 0x81 = S3P_PING_RESPONSE |
| 1 | Status/error code |
| 2 | Flags bits: 0: 1=Tool has said calibrations synchronised since reset/status cleared 1..7: Reserved |
Read (upload) Memory using 4-byte address
Request message:
| 0 | 0x02 = S3P_READ_MEMORY_REQUEST |
| 1 | Number of bytes to upload (max 253) |
| 2..5 | Address of first byte to upload |
Respone message:
| 0 | 0x82 = S3P_READ_MEMORY_RESPONSE |
| 1 | Status/error code |
| 2.. | Raw data read from ECU memory |
Write (download to RAM) Memory using 4-byte address
Request message:
| 0 | 0x03 = S3P_WRITE_MEMORY_REQUEST |
| 1..4 | Address of first byte to write |
| 5.. | Raw data to write to ECU memory (length implied by total payload size, max 250) |
Respone message:
| 0 | 0x83 = S3P_WRITE_MEMORY_RESPONSE |
| 1 | Status/error code |
Accessibility