ISL78610 Datasheet, PDF (74/98 Pages) Intersil Corporation – Multi-Cell Li-Ion Battery Manager

ISL78610
A Check Register Checksum command recalculates the Page 2
checksum and compares it to the internal value. The occurrence
of a Page 2 checksum error sets the PAR bit in the Fault Status
register and causes a Fault response accordingly. The normal
response to a PAR error is for the host microcontroller to rewrite
the Page 2 register contents. A PAR fault also causes the device
to cease any scanning or cell balancing activity.
See items 42 through 49 in Table 47 on page 76.
Communication Faults
There is no specific flag to indicate a communications fault. A
fault is indicated by receiving an abnormal communications
response or by an absence all communications.
Non-daisy chain device commands and responses use CRC
(Cyclical Redundancy Check) error detection. (Stand-alone
systems do not use the CRC.) If a CRC is not recognized by a
target device, a command includes an Address All when it is not
allowed, or if there are too few bits in the sequence there is a
NAK response. The host can tell where this fault occurred by
reading the Device address.
If there is no response, then there is a communications failure.
Communication Failure
All commands except the Scan, Measure and Reset commands
require a response from either the stack top device or the target
device (see Table 10 on page 40), each device in the stack waits
for a response from the stack device above. Correct receipt of a
command is indicated by the correct response. Failure to receive
a response within a timeout period indicates a communications
failure. The timeout value is stack position dependent. The
device that detects the fault then transmits the communications
failure response which includes its stack address.
If the target device receives a communications failure response
from the device above then the target device relays the
communications failure followed by the requested data (in the
case of a read) or simply relays the communications failure only
(in the case of a Write, Balance command, etc). The maximum
time required to return the communications failure response to
the host microcontroller (the time from the falling edge of the
24th clock pulse of an SPI command to receiving a DATA READY
low signal) is given for various data rates in Table 44.
TABLE 44. MAXIMUM TIME TO COMMUNICATIONS FAILURE RESPONSE
MAXIMUM TIME TO
ASSERTION OF DATA READY
DAISY CHAIN DATA RATE (kHz) 500 250 125 62.5 UNIT
Communications Failure Response 5.8 11.6 23.2 46.4 ms
A communications fault can be caused by one of three
circumstances:
• The communications system has been compromised,
• The device causing the fault is in Sleep mode, or
• A daisy chain input port is in the wrong idle state
This latter condition is unlikely but could arise in response to
external influence, such as a large transient event. The daisy
chain ports are forced to the correct idle condition at the end of
each communication. An external event would have the potential
to “flip” the input such that the port settles in the inverse state.
A flipped input condition recovers during the normal course of
communications. If a flipped input is suspected, having received
notification of a communications fault condition for example, the
user may send a sequence of all 1’s (e.g., FF FF FF FF) to clear the
fault. Wait for the resulting NAK response and then send an ACK
to the device that reported the fault. The “all 1” sequence allows
a device to correct a flipped condition via the normal end of
communication process. The command FB FF FF FF also works
and contains the correct CRC value (should this be a
consideration in the way the control software is set up).
If the process above results in a communications failure
response, the next step is for the host microcontroller to send a
Sleep command, wait for all stack devices to go to sleep, then
send a Wake-up command. If successful then the host
microcontroller receives an ACK once all devices are awake. In
the case where a single stack device was asleep, the devices
above the sleeping device would not have received the Sleep
command and would respond to the Wake-up sequence with a
NAK due to incomplete communications. The host
microcontroller would then send a command (e.g., ACK) to check
that all devices are awake. This process can be repeated as often
as needed to wake up sleeping devices.
In the event that the Wake-up command does not generate a
response, this is a likely indication that the communications
have been compromised. The host microcontroller may send a
Sleep command to all units. If the communications watchdog is
enabled, then all parts go to Sleep mode automatically when the
watchdog period expires as long as there are no valid
communications activity. Table 10 on page 40 provides a
summary of the normal responses and an indication if the device
waits for a response from the various communications
commands.
Daisy Chain Communications Conflicts
Conflicts in the daisy chain system can occur if both a stack
device and the host microcontroller are transmitting at the same
time, or if more than one stack device transmits at the same
time. Conflicts caused by a stack device transmitting at the same
time as the host microcontroller are recognized by the absence
of the required response (e.g., an ACK response to a write
command), or by the scan counter not being incremented in the
case of Scan and Measure commands.
Conflicts which arise from more than one device transmitting
simultaneously can occur if two devices detect faults at the same
time. This can occur when the stack is operating normally (e.g., if
two devices register an undervoltage fault in response to a Scan
Voltages command sent to all devices). It is recommended that
the host microcontroller checks the Fault Status register
contents of all devices whenever a Fault response is received
from one device.
Loss of Signal from Host
A watchdog timer is provided as part of the daisy chain
communications fault detection system. The watchdog has no
effect in non-daisy chain systems.
Submit Document Feedback ₇₄
FN8830.1
June 16, 2016