HIP7010 Gryphon driver information

These notes assume you are familiar with existing Gryphon VPW J1850 devices, or you are at least able refer to the documentation to them. (My own notes on the DLC driver can be found at: http://www.ratltd.co.uk/gryphon/dlc.txt )

I realise some of these explantions etc aren't very good, try not to feel frustrated if you don't at first understand what I'm trying to convey.


Chip that implements J1850 on Chrysler card is an Intersil HIP7010 'Byte Level Interface Circuit'. The term 'BLIC' is used in the HIP7010 datasheet, and I've also used it anywhere where 'HIP7010' is too unwieldy (i.e. almost everywhere).

The ioctls are the same ones used for the DLC card. If this offends Chrysler people, we can use 'VPW' instead of 'DLC' and make one an alias for the other. Chrysler and GM J1850 are the same protocol, deliberately making ioctls dissimilar between similar channels would be needlessly impractical.

Summary of how the HIP7010 device is different to the DLC device



Supported ioctls:




- returns GJ1850 and GHIP7010




- Unfortunately the HIP7010 doesn't support 4x mode transmits. Also, because the HIP7010 is byte based, 4x mode is kind of on the limit of the interrupt rate of what PC like hardware such as gryphon will handle, the device may malfunction if gryphon is coping with other tasks (e.g. high speed CAN monitoring) whilst receiving 4x traffic.


- unlike the DLC the default mode will be GDLCHDRONEOBD which is a better choice for Chrysler people.


- only one mode so far though, GDLCRXDEFAULT. Supported mainly for compatibility reasons and in case of future need.

In addition all the GET/SET counter ioctls are supported by the dcx module:


Ioctls not supported:


New ioctls the HIP7010 driver supports, not previously supported by other devices


- Adds an IFR 'response' to the driver. A 'response' consists of the IFR data the device should send, criterea the received normal message data should meet before the driver attaches the IFR to it, whether the normalisation bit should be set, and also, (purely because of limitations of the Intersil HIP7010 chip) how many bytes of normal data the message being replied to will have (i.e. the user has to tell the device what is likely to happen on the bus, as strange as that seems).

Note: the driver currently only supports one response being loaded at a time. Subsequent GVPWADDIFR ioctl calls will simply overwrite the last response loaded. The ability to load more than one response may be added to the driver in the future.


offset		length		description
------		------		-----------

0		2 bytes		pattern length
2		2 bytes		ifr length

4		1 byte		normalisation bit (boolean, 0 or 1)
5		1 byte		reserved
6		2 bytes		'message length', number of bytes to receive
				before giving HIP7010 ifr data

8		patternlen	pattern to match incoming message against
				when deciding whether IFR is sent.

8+patternlen	patternlen	mask to use for above pattern, 0=dont care,
				1= bit in message must match bit in pattern.

8+patternlen*2	ifrlen		ifr data to send in response to message
				matching the pattern/mask


- removes any/all IFR responses (as loaded by GVPWADDIFR) from the driver.

Events supported



- except the single byte of data will be the HIP7010's status register instead of the DLC's CCBR. Not that client code will be interested in the data in either case normally.


- new event, means one out of a whole list of errors has occurred (no, the HIP7010 doesn't tell us which one). A list could be drawn up from the datasheet if someone needs it.


- new event, means the HIP7010 decided to reset itself, probably due to a slow clock. this should never happen, unless you're trying to diagnose a faulty gryphon card or one thats being abused to the point of malfunction.

Some generic events also supported, including the one that tells you when the speed changes (like the DLC, this will happen if the HIP7010 is in 4x mode and drops back to normal speed because it sees a break, or if you or another client changes the speed).

Events not supported


Data frame format

hdrlen is the same as for the DLC but the default mode will be "one byte headers, except when its J1979 OBD-2 messages, in which case it'll be 3." This is what Rich Means reckoned Chrysler people would expect. Note that in exceptional conditions hdrlen may be zero regardless of what hdrmode the device is in, so this condition should be tolerated by client software (e.g. by just ignoring the message, if it doesn't know what to do with it). Similarly in 3 byte header mode, you may get less than 3 bytes, but this is no change from the DLC - 1 & 2 byte long J1850 messages are nothing particularly outrageously odd.

Block mode is supported so datalen can be anything from 0 to the maximum a gryphon frame can carry, which is currently 7168 bytes (as #defined by MAXPAYLOAD).

Extralen. Same as the DLC - limited to 255 by the integer size. Unlike the current DLC driver the first byte of extradata will be the data CRC. The rest of the bytes will be IFR data (if any).

Messages with extralen set to zero should be tolerated by client code, even though the HIP7010 normally at least puts the data CRC in extradata and thus extralen is normally at least one. (Firstly to remain compatible with other J1850 hardware versions, both now and in the future. Secondly, the BLIC driver could, under exceptional circumstances, give the user messages with extralen being set to zero, for instance if the HIP7010 declared the first byte it received to be IFR data (why it would do this, I don't know, but if it did somebody would want to know about it as its kind of an odd thing for it to do).)

The IFR normalisation bit will be indicated by a bit in the stat field, same as the DLC.