KWP ioctls


Parameters marked with 'VSONI' are only guranteed to be updated during the next (hard) initialisation. (VSONI = Value Set On Next Initialisation.) Unfortunately due to the nature of the keyword card, it can't be guaranteed that 'VSONI' parameters wont be updated until initialisation, they probably wont, but client code should not rely on this. Given this, certain parameters may cease to be 'VSONI' parameters in future driver versions in order to try to reduce the amount of confusion here.

Parameters marked with 'VSI' are changed immediately. (VSI = Value Set Immediatedly). This document uses this marking just confirm to the reader that the parameter isn't a 'VSONI' parameter, and they do not need to initialise the channel for the change to take effect.

All integers in arguments are in x86 byte order.




GKWPGETBITTIME
GKWPSETBITTIME

Arguments: 2 bytes	- bit time (microseconds) 0x0060 = 10,400 bits/sec
VSONI



GKWPSETPTIMES

Arguments: 24 bytes
VSI

		0,1	- P1 rx min  (half milliseconds, 'x86' byte order)
		2,3	- P1 rx max	"		"
		4,5	- P1 tx		"		"

		6,7	- P2 rx min	"		"
		8,9	- P2 rx max	"		"
		10,11	- P2 tx		"		"

		12,13	- P3 rx min	"		"
		14,15	- P3 rx max	"		"
		16,17	- P3 tx		"		"

		18,19	- P4 rx min	"		"
		20,21	- P4 rx max	"		"
		22,23	- P4 tx		"		"

The first two values for each P time specify a valid range that is used by
the device to interpret the byte traffic from the bus.  The device may
indicate a timing violation error to the user should it see traffic violating
this range.  The third value for each P time is the time the device should
use when transmitting.  For normal use the third value should be somewhere
in between the first two values.



GKWPSETWTIMES

Arguments: 30 bytes
VSI

		0,1	- W1 rx min  (half milliseconds, 'x86' byte order)
		2,3	- W1 rx max	"		"
		4,5	- W1 tx		"		"

		6,7	- W2 rx min	"		"
		8,9	- W2 rx max	"		"
		10,11	- W2 tx		"		"

		12,13	- W3 rx min	"		"
		14,15	- W3 rx max	"		"
		16,17	- W3 tx		"		"

		18,19	- W4 rx min	"		"
		20,21	- W4 rx max	"		"
		22,23	- W4 tx		"		"

		24,25	- W5 rx min	"		"
		26,27	- W5 rx max	"		"
		28,29	- W5 tx		"		"



GKWPSETSTARTREQ

Arguments: 5 bytes	- fast wake up start communication request
VSI



GKWPSETSTARTRESP

Arguments: 8 bytes	- fast wake up start communication response
VSI



GKWPGETNODETYPE
GKWPSETNODETYPE

Arguments: 1 byte	- node type, GKWPMONITOR / GKWPTESTER / GKWPECU
VSONI



GKWPSETPROTOCOL

Arguments: 1 byte	- protocol, GKWPKWP2000 / GKWPISO9141FORD
VSONI



GKWPSETNODEADDR

Arguments: 1 byte	- node address
VSONI  (slight bug here, the value thats used for wake ups _may_ also be
	updated if some of the other ioctls are used, as well as on
	initialisation.  The situation is complicated by the fact that the
	card asks for node addresses just as part of its initialisation,
	and I'm not exactly clear what it does with them or what it wants
	them for when the parameters envolved for the wake up stuff
	(including node addresses) are set up elsewhere.  I could hack
	round this in the driver, admittedly.  Actually all this is a
	little insignificant anyway, as all the keyword VSONI values get
	updated if the J1850 channel gets initialised (and vice versa).
	I guess I'll mention that at the top of this document, in which
	case this comment can probably be deleted.)



GKWPSETWAKETYPE

Arguments: 1 byte	- wakeup type, GKWPFAST / GKWPFIVEBAUD
VSI



GKWPSETTARGADDR

Arguments: 1 byte	- address of node to wake up
VSI



GKWPSETKEYBYTES

Arguments: 2 bytes	- keybytes to send in (5 baud) wake up process
VSI



GKWPDOWAKEUP

Arguments: 0 bytes



GKWPGETLASTKEYBYTES

Arguments: 2 bytes	- value of keybytes seen in last successful wake up
			(only currently implement for 5 baud)


GKWPSETLASTKEYBYTES

Arguments: 2 bytes	- value GKWPGETLASTKEYBYTES returns until a
VSI			  successful wake up is seen.




KWP events





GKWPWAKEFIVE		- 5 baud wakeup seen

Data:
	byte 0	- 5 baud address	   (tester)
	byte 1	- sync byte		   (ecu)
	byte 2	- first keybyte		   (ecu)
	byte 3	- second keybyte	   (ecu)
	byte 4	- inverted second keybyte  (tester)
	byte 5	- inverted address	   (ecu)

	byte 6	- status 0 = timing good

Note any length of data should be tolerated by client.  Currently implemented
lengths are 1 (i.e. an unsuccessful wake up) and 7.  Longer data lengths may
occur in the future if more information is appended to this event.



GKWPWAKEFAST		- fast wakeup seen

Data:
	byte 0	  - the WuP as interpretted by a uart, i.e. usually 0xf0
	byte 1-5  - the start communication request message.
	byte 6-   - the start communication response message

Again, any length of data should be tolerated by client.



GKWPBUSIDLE		- intermessage time elapsed since last byte

Data:
	byte 0,1  - time expired (in units of half milliseconds,
		    network byte order).



In addition to the events above, acknowledgements from the card's dual port ram communication mechanism also generate events. These can be distinguished by the fact the most significant bit of the event number is set. Normal users should either not enable event numbers greater than 127, ignore these events, or contact Gryphon development if their application needs any functionality these events may offer.





KWP stat bits





GKWPSTAT_KLINE		Message on K line (rx and tx)
GKWPSTAT_LLINE		Message on L line (rx and tx)
GKWPSTAT_ERR		General bus error (rx only)
GKWPSTAT_CSERR		Checksum error (rx only)
GKWPSTAT_CONTENTION	Bus contention detected (rx only)
GKWPSTAT_BLOCK		Message received over multiple interrupts (rx only)