Figure 4-1 Suggested Communications Flow
Power On or Hardware Reset
0x0F
Get
'Last command'
0x0E
Setups CRC
Check
0x01
Load Setups
Block
0x04
Force Reset
0xF0
returned
Setups CRC
failed 1x
0xF0 not
returned
CRC is OK
No key,
no error
Setups CRC failed 2x
0x06
Report 1st Key
~10ms Delay
0x05
Get
General Status
Any Error Flag
(highest
precedence)
2 Keys
Detected
m
0x0F
Get
Only 1 Key
in Detect
Comms
Error
'Last command'
(clear error)
0x07
Report all
detections
Keys OK
eeprom corrupt, or
calibration fail, or
FMEA fail, or
Internal Host
Processes
multiple errors
resolvable
error
Key Detection(s) Processing
Error Handling
Comms with
QT
FMEA Calibration
Error
Stuck Key
Detected
Error
Note: CRC errors or incorrect
responses should cause
each transmission to retry
Done
0x0B
0x0C
Get
FMEA Status
0xck
Cal Key 'k'
Get
Errors for All
Keys
where changes are specifically required, such as for sensitivity,
timing, or AKS changes.
Error handling takes place whenever an error flag is detected,
or the device stops communicating (not shown). The error
handling procedure is up to the designer, however normally this
would entail shutting down the product if the error is serious
enough (for example, a key that will not calibrate, or a FMEA
class error).
The circles in this drawing are communications interchanges
between host and sensor. The rectangles are internal host
states or processing events. If any communications exchange
fails, either the device will fail to respond within the allotted time,
or the response CRC will be incorrect, or the response will be
out of context (the response is clearly not for the intended
command). In these cases the host should just repeat the
command.
Normally it is not required to reload the setups, since the device
itself stores a backup copy of these in Flash memory should the
eeprom become corrupt. However the host should reset the QT
so that the device will copy the Flash setups to eeprom, and
then the QT should check that the eeprom CRC code is correct.
Only if this fails should the eeprom be reloaded by the host.
One exception to this rule is just after powerup, since a CRC
error in the eeprom setups at this point is clearly a critical error
that would require reloading. This happens at the factory, during
the very first powerup cycle.
The control flow will spend 99% of its time alternating between
the two states within the dashed rectangle. If a key is detected,
the control flow will enter ‘Key Detection Processing’.
Stuck Key Detection processing (0xck) is optional, since the
device contains the max on-duration timeout function and can
therefore recalibrate the stuck key automatically. However, the
host can recalibrate stuck keys with greater flexibility if the
recalibration timeouts are set to infinite and the host recalibrates
them under specific conditions.
The ‘Last Command’ command can be used at any time to clear
comms error flags and to resynchronize failed communications,
for example due to timing errors etc.
lQ
17
QT60486-AS R8.01/0105