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:
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
- Interpretation of the IFR normalisation bit the way Chrysler & SAE J1850
- Support for transmitting IFR in response to another node's message.
- Shows actual incorrect CRC bytes rather than just warning of CRC errors.
- No 4x transmit.
- Less extensive error event reporting.
- Can't send J1850 break.
- No software configurable bus termination.
- Byte based rather than message based means device is more resource hungry
and less suitable for applications where gryphon has a very high system load.
- 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
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
- 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
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.