ZHCSCS9 SEPTEMBER 2014 TPS92661-Q1
PRODUCTION DATA.
The TPS92661 lighting matrix manager (LMM) device, in conjunction with a buck switching current regulator, enables a fully dynamic matrix beam solution where each LED can be individually controlled. This type of control of an LED array is ideally suited for dynamic headlight applications where adaptive beam forming requires pixel level control of the array.
The TPS92661 device configures 12 series connected low voltage switches (MOSFETs) that can float up to 67 V above ground potential. Each switch connects in parallel to one LED, thereby creating individual shunt paths across each LED of a series string of 12 LEDs. LED strings with fewer LEDs can be used, however the unused channels should be physically shorted externally to reduce unnecessary internal power consumption.
Each switch has an individual driver, overvoltage protection circuit and diagnostics circuit referenced to the source of that switch. This configuration allows for fully dynamic operation with the switches above it and below it. The device monitors overvoltage conditions on each switch and automatically protects them in the event of an open LED connection. The device detects open LED conditions as well as shorted LED conditions and reports them through the fault reporting network.
All twelve internal bypass switches can be individually pulse width modulated (PWM) at a programmed frequency and duty cycle. This PWM dimming topology provides Inherent phase shifting capability. In addition, the switch transitions during PWM dimming are slew rate limited to mitigate any EMI concerns due to the di/dt and dv/dt of the switching action.
The TPS92661 device also provides multi-drop UART communications capability between a host MCU and up to 8 slave TPS92661 devices. The UART receives data corresponding to the desired PWM information for all 12 internal switches. In addition, it can send back fault and other diagnostic data to the host MCU. Hardware connections on the three address pins allows addressing of the eight devices.
An internal regulator accepts the 5-V power supply input for the TPS92661 device and generates a 3.3-V regulated output for the I/O buffers used in the internal UART. The internal regulator can be bypassed by shorting VIN to VCC if 5-V communication is desired.
The combination of features in the TPS92661 device provides the ideal interface for individual control of high current LED arrays. The Figure 27 shows a dynamic headlight application using multiple TPS92661 devices. The electronic control unit (ECU), usually attached to the outside of the headlight, contains the master MCU, a boost pre-regulator stage that takes the variable battery voltage and steps it up to a stable DC voltage rail. The application includes multiple channels of buck current regulators to provide a stable current through each series string of 12 high brightness LEDs. The TPS92661 device should reside on the LED load board where it is as close as possible to the LEDs to which it directly connects.
This location has two major benefits.
Ultimately, the TPS92661 device enables an optimal partition for a flexible, high performing dynamic headlight system.
The TPS92661 device (LED Matrix Manager) consists of 12 series connected bypass switches between terminals LED12 and LED0. Each bypass switch, when driven to an off state, allows the string current to flow through the corresponding parallel-connected LED, turning the LED on. Conversely, driving the bypass switch to an on state shunts the current through the bypass switch and turns the LED off.
Each single switch (connected between LEDn and LEDn–1) has a measurable typical RDS(on) value of 225 mΩ. This measurement includes the actual on-resistance (RDS(on)) of the switch and the resistance of the two internally connected bond wires. When multiple series switches are on, the effective resistance is not simply the number of channels multiplied by 225 mΩ because there are not two conducting bond wires for every series-connected switch. For this reason the all-switches on-resistance (RALL(on)) is specified in the Electrical Characteristics table. This value includes the twelve RDS(on) on-resistances and the resistance of the bond wires at each end of the series connected switches.
The dominant power loss mechanism In the TPS92661 device, is I2R loss through the switches. Other power loss sources are always less than 50 mW. When calculating the power dissipation of the TPS92661 device switches, use Equation 1 for the best estimation of this power loss.
where
See the 6 LED, 1.5-A Application section for a sample calculation.
The TPS92661 device provides 10-bit PWM dimming of each individual LED. The LED turn-on and turn-off times are separately programmed for each LED. The LEDxON registers and LEDxOFF registers (where x = 1 to 12) determine the LED turn-on and turn-off times, respectively, within the PWM dimming period. Phase shifting can be accomplished by staggering the LEDxON times or LEDxOFF times. The 10-bit internal PWM Period Counter (TCNT) is compared against the LEDxON and LEDxOFF values.
When TCNT reaches the programmed LEDxON value for a given LED, the corresponding bypass switch is turned off to force current through the LED. Similarly, when TCNT reaches the programmed LEDxOFF value, the bypass switch is turned on to turn off the LED. TCNT counts continuously from 0 to 1023 and returns to 0 again. The LED PWM dimming period equals 1024 times the internally divided, programmable PWM clock period. Figure 9 shows an example of LED PWM using values of LEDxON = 250 and LEDxOFF = 800.
Because the LEDxON and LEDxOFF times are completely programmable, this allows the system flexibility to phase shift the leading edge (LED On), the trailing edge (LED Off), or double-edge PWM.
The comparison circuitry consists of a digital comparator, along with an AND gate to allow that particular comparison to propagate to the LED switch. The TCNT counter value is continuously compared against the value programmed into the LED On/Off registers. The ENON bit that corresponds to that particular LED determines whether or not that comparison has any effect at the LED. The logic is represented in Figure 10.
The PWM clock that drives TCNT is a divided-down version of the CLK input. The divider is programmed by writing to the PWM clock divider register (PCKDIV). The divider comprises two dividers in series: a power-of-2 clock divider followed by a decimal count divider (see Figure 11 and PWM Clock Divider Register (PCKDIV) for PCKDIV bitmap). Upon power-up, the PWM clock divider is programmed to a divisor value of 16.
Upon power-up, the TCNT counter is reset to 0. The TCNT counter is clocked by the internal PWM clock. In order to correctly synchronize multiple TPS92661 devices on the same network, two conditions must be met:
Assuming that these conditions are met, the TPS92661 devices may be synchronized by either of two methods:
NOTE
In order to prevent bus contention, ensure that the network design includes only one synchronization master.
Figure 13 and Figure 14 show an example of two non-synchronized TPS92661 devices and two synchronized devices respectively. In this example all twelve channels on each device are programmed with LEDON = 0 and LEDOFF = 128. In the non-synchronized example TCNT = 0 occurs at two different places in time. By using the SYNC function, TCNT = 0 occurs simultaneously for both devices.
CH1: (Dark Blue) Device 1 LED string voltage | ||
CH2: (Light Blue) Device 2 LED string voltage | ||
CH3: (Pink) SYNC signal as generated by 1 device |
CH1: (Dark Blue) Device 1 LED string voltage | ||
CH2: (Light Blue) Device 2 LED string voltage | ||
CH3: (Pink) SYNC signal as generated by 1 device |
The gate drive control of each series switch slows the rate of change of current through the device. This control eases EMI requirements and aids in the system operation. The switching transition controls the current through the switch at each edge to approximately 800 mA/2 µs. The internal circuitry of the device controls the slew rate. The user cannot change the slew rate. The rise and fall slew rates are matched to ensure accurate representation of the PWM duty cycle. These slew rates assume no LED string capacitance.
Figure 16 and Figure 17 show the effective system input current (CH4, green trace) and V(LED12-LED0) string voltage (CH1, blue trace) for various phase shift settings. The results illustrate the advantages of adjusting the phase shift value to minimize the variation in input current. Figure 16 illustrates a zero phase shift condition by setting all twelve LEDxON values to zero and all twelve LEDxOFF values to 128. Figure 17 illustrates optimal phase shifting where all twelve LEDxON values are spaced by a count of 85 (0, 85, 170, 235, ...). The input current variation is greatly reduced with optimal phase shifting as all twelve channels do not draw current from the input simultaneously. This reduces demands on the energy storage capacitance at the system input.
No Phase Shift | Duty Cycle = 128/1024 |
Phase Shift = 85 | Duty Cycle = 128/1024 |
Each individual bypass switch is driven by a floating driver which is powered by the charge pump (see Functional Block Diagram). The steady floating driver supply also enables continuous protection and monitoring of LED open and short events.
In the event of an OPEN LED failure, an internal comparator monitors the drain-to-source voltage of the internal switch. If the voltage exceeds VTH-O (typical 6 V) the device overrides the switch-off signal and turns on the switch. This action maintains current flow in the rest of the LED string in the presence of a faulty or damaged LED and protects the internal switch. The internal latch holds this state until a subsequent on and off cycle at which time the switch attempts to turn off again, and the condition is re-evaluated. The protection circuit also sets the corresponding bit in the FAULT register described in the Diagnostic Registerssection . The controller can poll this register to determine whether a fault has occurred.
When the device resets a FAULT bit in the register array by writing the bit back to zero, it then clears the latch and re-enables the OPEN switching transition of the corresponding LED. This feature allows the controller to perform multiple checks of the LED fault so that false LED faults can be filtered via software.
Similar to LED open detection, an LED short is detected via monitoring the drain-to-source voltage of the internal switch. If the voltage does not exceed the VTH-S threshold by the end of the PWM cycle, the same fault register bit is set. Both short and open cases are handled by the same register as each case has the equivalent outcome, which is that the channel is bypassed. (see Figure 18)
Fault detection and protection occur immediately and are independent of any internal clock. The device detects an overvoltage condition when the channel voltage rises to the OVP (overvoltage protection) comparator threshold. The channel switch is then latched ON with a delay of approximately 50 ns (typical). This detection generates a fault signal that is sent to the internal fault register when TCNT = LEDxOFF where it can be polled by the user. Similarly, the short detection fault signal is sent with the same timing. The Diagnostic Registers are updated in a maximum time of one full PWM period (a PWM count of 1024). Due to internal propagation delays the LED On-time count must conform to Equation 2 for accurate fault reporting. For typical applications this may require fault reporting to be ignored at duty cycles less than 1%.
In an LED open event, 12 LEDs are being turned on sequentially, creating the staircase waveform as shown in Figure 20. At approximately time = 280 µs, LED6 is commanded to turn on but it is open. The TPS92661 device fault circuit immediately clamps the node by turning the channel switch ON. As the LEDs in the string are turned off, the previously open LED remains shorted for that cycle as the system has detected the fault and forced the switch to stay on. Other channels continue to operate normally.
To help eliminate glitches in the LED current during register updates, the TPS92661 device implements the atomic multi-byte writes function and the synchronous updates function.
Because the LEDxON and LEDxOFF registers are 10-bits wide and span across multiple bytes, there is a chance that during the time between the serial transmission of the lower eight bits and the upper two bits the resulting register value is wrong. To overcome this problem, the communications protocol provides for atomic multi-byte writes. This function updates all of the desired registers at one time, only after receiving an entire transaction frame. For example, only after the entire nine-byte transaction frame has been successfully received, does the device issue a write command to registers 00H-04H (which represent the LED1ON, LED2ON, LED3ON and LED4ON registers) and transfers it to the final registers. This transfer has the additional benefit of updating the final registers only if the cyclical redundancy check (CRC) for the transaction frame is correct.
Serial communications are asynchronous to the TCNT period. The device can write LEDxON and LEDxOFF with any value from 0x000 to 0x3FF at any time within the TCNT period. Consider a situation where there are no timing restrictions on updating the final registers. When the device receives a new LEDxOFF value while the corresponding LED is on and TCNT is already greater than the new LEDxOFF value, the LED remains on until it reaches the LEDxOFF value in the next TCNT period. This can appear as a glitch in LED light output.
To overcome this issue, the device writes a new value LEDxOFF and stores it in a temporary register. The device updates the final register only after TCNT reaches the next LEDxON register value. The converse is true for write commands to a particular LEDxON. In that case, the device updates the final register only after TCNT reaches the next LEDxOFF value. This sequence allows the device to update the LEDxOFF registers at the corresponding LED turn-on time and update the LEDxON registers at the corresponding LED turn-off time.
When LEDxON and LEDxOFF are both set to the same value, the device interprets the setting as an LED off condition. This is equivalent to clearing the ENON bit for that particular LED. The next time TCNT reaches the common LEDxON and LEDxOFF value, the device ignores LEDxON and the LED turns off (if it was on) and remains off until the device writes LEDxON and/or LEDxOFF and updates them with different value(s). More specifically, the LEDOFF comparison takes precedence over the LEDON comparison. Figure 21 illustrates an update example. Case (1) shows the resulting single PWM cycle on time that would occur if the writing of the registers were not handled through a temporary register. Case (2) shows the functionality of the TPS92661, where the register update is controlled, eliminating a false conduction cycle.
The synchronous update method removes a large majority of glitches that could be caused in the light output, but one case should be considered. The reason is based on the synchronous update technique and can occur when reducing the PWM duty cycle to zero. If the duty cycle is controlled by the LEDxOFF time, the LEDxON count is fixed each cycle. To dim, the LEDxOFF count will be gradually reduced. Because of the way the LEDx ON/OFF updates occur, a glitch can occur at the point when LEDxON = LEDxOFF causing the LED to remain on for a single cycle. The recommended method to turn a channel fully off is to avoid the implementation of LEDxON = LEDxOFF and use the corresponding ENON bit in the Enable Register for that channel. For example, to dim a given channel to zero duty cycle: LEDxOFF reduces to LEDxON+1, then sets that channel's ENON bit to 0.
The TPS92661 device includes two watchdog timers: a Clock Watchdog Timer and a Communications Watchdog Timer. The clock watchdog timer operates using a free-running internal oscillator. The communications watchdog timer operates using the incoming CLK signal. Both watchdog timers only operate when enabled after power-up by writing their respective enable bits to a 1 in the SYSCFG register (CKWEN for the clock watchdog timer and CMWEN for the communications watchdog timer). The Default LED State Register (DEFLED) determines which state the LEDs are placed in during a watchdog timeout period. (see the Default LED State Register (DEFLED) ) section for details.
The Figure 22 shows the subsequent state flow after a watchdog timer limit is reached.
If the external CLK input stops toggling for 32 internal oscillator cycles ( approximately 14 µs, typical) the clock watchdog timer times out and all of the LEDs are turned on or off according to the programmed values in the DEFLED register. They remain in that state until CLK begins toggling again. During this time, the device does not receive or transmit UART communications. The device does not reset the internal registers in the event of clock loss, and the LEDs begin turning on and off according to their LEDxON/LEDxOFF register settings only when the clock returns. If the clock watchdog timer is not enabled the TPS92661 is capable of operating at frequencies down to 0 Hz.
Similarly, if the CLK remains running but the device receives no transaction with a correct CRC for a period of 222 CLK cycles, the communications watchdog timer times out and the device sets the LEDs to the state defined in the DEFLED register. Only after a valid UART command has been received with a correct CRC do normal PWM duty cycles resume on the LED outputs.
The TPS92661 device may be configured and controlled using a MCU connected via a standard serial UART. Up to eight devices may be connected to the same UART to form a network.
The address pins should be tied to VIN or GND to set the address of the TPS92661. Up to eight TPS92661s can exist on the same network. See Table 2 for a summary of device address configurations.
The CLK pin is the input for the primary system clock. It serves as the time basis for both the UART, as well as the LED PWM hardware. The device functions with a clock input as high as 16 MHz. The clock rate should be selected based on the desired UART bit rate. CLOCK can be provided by the PWM peripheral of the master microcontroller, or by a local oscillator. All TPS92661s on the same network should share the same clock.
The CPP pin functions as the output of the internal charge pump. The device uses the charge pump voltage as the gate drive voltage for the internal floating switches. Bypass the CPP pin to the LED12 pin with a capacitor with a value of at least 0.1 µF.
The ENABLE pin is an active-high enable signal for the TPS92661 device. When driven low, it resets all internal switches, state machines, and registers to their default states. The reset state of the switches is closed, and registers are reset (see Table 7). The managing microcontroller can actively drive this pin. Alternatively tie this pin to VCC or VIN to enable the device at power-up. The EN pin input has internal protections against charge injection and requires no series resistor when tied to one of the local power rails.
Proper operation of the TPS92661 device requires that all GND pins MUST be tied to system ground.
The RX pin is the TPS92661 UART input. It should be connected to the UART Tx pin of the MCU, as well as the other TPS92661 RX pins on the network. The bit rate of data transmitted on this pin should be at CLOCK / 16, and is fixed at that bit rate.
The SYNC pin synchronizes the internal PWM counter of the TPS92661 device. At reset, the SYNC pin acts as an input, and a low-to-high pulse on this pin resets the TCNT register to 0x000. When an external microcontroller drives this pin, the pulse should be generated at the LED PWM frequency. To calculate this frequency, use Equation 3.
Writing a ‘1’ to the SCMAST bit in the SYSCFG register programs the SYNC pin to function as an output. Establish only one TPS92261 device as the master if the application requires this output configuration. To prevent contention on the SYNC line configure only one SYNC master (driver) in the system at a time. The SYNC pin is internally pulled down and can remain unconnected if it is not used.
The TX pin is the UART output of the TPS92661 device. Connected the TX pin to the microcontroller UART RX pin. The bit rate of data transmitted on this pin is fCLK/16, and is fixed at that bit rate. Connect all TX pins on each TPS92661 device that are on the same network. Connect a single, 100-kΩ pull-up resistor from TX to VCC. Because the TX pin is a tri-state output, an external pull-up resistor is required to avoid triggering false start conditions at the microcontroller UART.
The VIN pin is the primary power supply input for the TPS92661 device. Connect the VIN pin to a nominally 5-V supply, and include a bypass capacitor nearby with a value of at least 0.1-µF.
The VCC pin is the input for the positive rail of the internal digital I/Os. See the Internal Regulator section for configuration guidelines.
There are pin pairs for each digital I/O on the TPS92661 device. This allows for easy routing between multiple devices on a single sided PCB. To help estimate the voltage drop across the pin-to-pin connection, see Figure 26.
The microcontroller unit UART communicates with the TPS92661 device using serial TTL signaling. The TX and RX lines are connected to the TPS92661 device as shown in Figure 27. The pairs of TX and RX pins on the TPS92661 device are feed-through pins, and either pin may be used to connect the TPS92661 device to the network.
A tri-state buffer drives the TX output. In order to prevent false START bit detection by the microcontroller unit when a TPS92661 device releases the bus, place an external, 100-kΩ pull-up resistor on the RX input return line of the microcontroller unit.
The UART operates with eight data bits, one stop bit and no parity (8 – 1). Figure 28 shows the waveform for an individual byte transfer on the TTL UART.
A logic “1” state occurs when the device drives the line to the VCC voltage. A logic “0” state occurs when the device drives the line to system ground. The line remains in the high/logic “1” state when idle. Figure 29 and Figure 30 illustrate sending actual data bytes and are intended to represent what an actual UART waveform displays on an oscilloscope or logic analyzer.
The baud rate is based on the CLOCK input and is one-sixteenth of the CLOCK input frequency (see Table 1 for some examples). The UART uses 16× oversampling on the incoming asynchronous RX signal.
CLK FREQUENCY (MHz) | BAUD RATE (kbps) |
---|---|
6.4 | 400 |
8.0 | 500 |
12.8 | 800 |
16.0 | 1000 |
Set the master microcontroller unit to support the same baud rate as is defined by the input CLOCK frequency.
The microcontroller unit can reset the device UART and protocol state machine at any time by holding the RX input low for a period of at least 12 bit times (16 × 12 CLK periods). This period signifies a break in communications and causes the TPS92661 devices on the network to reset to a known-good state for receiving the next command frame. The device immediately aborts any response frames in progress.
NOTE
A communications reset does not reset the registers and does not halt normal LED PWM operation.
Connecting terminals ADR2, ADR1, and ADR0 to GND or VCC sets the device address for each TPS92661 device. This allows up to eight different devices (addressable (0h to 7h)) for a total of 8 × 12 = 96 LEDs per array. See Table 2 for device address configuration.
ADR2 | ADR1 | ADR0 | DEVICE ADDRESS |
---|---|---|---|
0 | 0 | 0 | 0 |
0 | 0 | 1 | 1 |
0 | 1 | 0 | 2 |
0 | 1 | 1 | 3 |
1 | 0 | 0 | 4 |
1 | 0 | 1 | 5 |
1 | 1 | 0 | 6 |
1 | 1 | 1 | 7 |
The UART communication process uses a command/response protocol mastered by the MCU to write and read the registers on each TPS92661 device. This means that the TPS92661 device never initiates traffic onto the network. The protocol maps the registers into an address space on each device. All of the registers are read-write (R/W). See the Registers section for a register list.
The MCU uses the protocol to initiate a communication transaction by sending a command frame. This command frame addresses either one TPS92661 device directly or broadcasts to all TPS92661 devices on the network. This addressing may cause a response frame to be sent back from the slave TPS92661 device depending on the command type of the command frame. There are three types of command frames:
There is only one response frame type. An addressed slave following a ‘Single Device Read’ command from the master MCU sends his frame type.
All command and response frames are multi-byte and the total number of transmitted bytes depends on the specific command type being communicated.
Command frame with CMD_TYPE = “2” (Single Device Write of 5 Bytes):
DESCRIPTION | NUMBER OF BYTES |
---|---|
Command Frame Init | 1 |
Starting Register Address | 1 |
Data | 5 |
CRC | 2 |
Total | 9 |
Response frame with RESP_BYTES = ”2”:
DESCRIPTION | NUMBER OF BYTES |
---|---|
Response Frame Init | 1 |
Data | 2 |
CRC | 2 |
Total | 5 |
Broadcast Write Synchronization Command frame (Init = B8h):
DESCRIPTION | NUMBER OF BYTES |
---|---|
Command Frame Init | 1 |
CRC | 2 |
Total | 3 |
The Transaction Frame Description section describes the construction of these frames and the various byte types transmitted.
There are four byte-types used within a transaction frame. These include the following:
Write & Read Command Frame Structure: |
Cmd Frame Init | Register Address | N Bytes of Data | CRC checksum |
Response Frame Structure: |
Rsp Frame Init | N Bytes of Data | CRC checksum |
Synchronization Command Frame Structure: |
Cmd Frame Init | CRC checksum |
The frame initialization byte identifies the frame as being either a command frame or response frame. The command frame byte includes fields specifying the request type (which details the number of bytes to be sent) and the slave device ID. The response frame includes the number of bytes to be received by the microcontroller.
7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | |
Command Frame Init | FRM_TYPE = 1 | CMD_TYPE | DEVID_DATACNT | |||||
Response Frame Init | FRM_TYPE = 0 | RESERVED | RESP_BYTES |
The fields shown in the frame initialization byte above are described in the table below.
Value (Binary) |
# of Bytes in Frame |
Description | |
---|---|---|---|
FRM_TYPE
Bit 7 |
0 | Response Frame | |
1 | Command Frame | ||
CMD_TYPE
Bits 6:3 |
0000 | 5 | Single Device Write (1 byte of data) |
0001 | 6 | Single Device Write (2 bytes of data) | |
0010 | 9 | Single Device Write (5 bytes of data) | |
0011 | 14 | Single Device Write (10 bytes of data) | |
0100 | 19 | Single Device Write (15 bytes of data) | |
0101 | Reserved | ||
0110 | Reserved | ||
0111 | 4+n | Broadcast Write (see DEVID_DATACNT for number of bytes of data) | |
1000 | 4 | Single Device Read (1 byte of data) | |
1001 | 4 | Single Device Read (2 bytes of data) | |
1010 | 4 | Single Device Read (5 bytes of data) | |
1011 | 4 | Single Device Read (10 bytes of data) | |
1100 | 4 | Single Device Read (15 bytes of data) | |
1101 | Reserved | ||
1110 | Reserved | ||
1111 | Reserved | ||
DEVID_DATACNT
Bits 2:0 |
For Single Device Write or Read: | ||
bbb | 3-bit device ID (defined by the terminals ADR2…ADR0) | ||
For Broadcast Write: | |||
000 | Synchronization Command (no data) | ||
001 | 1 byte of data | ||
010 | 2 bytes of data | ||
011 | 5 bytes of data | ||
100 | 10 bytes of data | ||
101 | 15 bytes of data | ||
110-111 | Reserved. These values are reserved for future use and must not be written. | ||
RESP_BYTES
Bits 2:0 |
000 | 1 data byte to follow (plus two bytes for CRC) | |
001 | 2 data bytes to follow (plus two bytes for CRC) | ||
010 | 5 data bytes to follow (plus two bytes for CRC) | ||
011 | 10 data bytes to follow (plus two bytes for CRC) | ||
100 | 15 data bytes to follow (plus two bytes for CRC) | ||
101-111 | Reserved |
The protocol allows 1, 2, 5, 10 or 15 successive register locations from the addressed register to be written by a single command frame. The register address byte identifies the first TPS92661 device register being written or read, as described in the Register Map section.
The frame initialization byte specifies the number of data bytes to be included in the frame.
CRC-16-IBM calculates the CRC bytes. The CRC bytes allow detection of errors within the transaction frame. The device increments the CRC Error Count Register (CERRCNT) each time a CRC error occurs (see Register Map for details).
The registers in the TPS92661 device contain programmed information and operating status. During the power-up period, the TPS92661 device resets the registers to the default values as listed below. Register addresses marked RESERVED or not shown in the register map may be written with any value but always returns a 0.
The device stores the LED ON registers (LEDxON) for each individual LED with 10-bit resolution and organizes them as groups of five bytes for every four LEDs. This organization creates a total of 15 LED ON registers for the string of 12 LEDs. The address range used for these registers is 00h to 0Eh. Refer to Table 7 for complete list of LED ON registers.
ADDR | REGISTER | D7 | D6 | D5 | D4 | D3 | D2 | D1 | D0 | DEFAULT |
---|---|---|---|---|---|---|---|---|---|---|
00h | LED1ONL | LED1ON[7:0] | 00000000 | |||||||
01h | LED2ONL | LED2ON[7:0] | 00000000 | |||||||
02h | LED3ONL | LED3ON[7:0] | 00000000 | |||||||
03h | LED4ONL | LED4ON[7:0] | 00000000 | |||||||
04h | LED1_4ONH | LED4ON[9:8] | LED3ON[9:8] | LED2ON[9:8] | LED1ON[9:8] | 00000000 |
LEDxON[9:0] defines the count value within the 10-bit TCNT period when bypass switch x should be opened to turn LEDx on (x = 1 to 12). |
The device stores the LED OFF registers (LEDxOFF) for each individual LED with 10-bit resolution and organizes them as groups of five bytes for every four LEDs. This organization creates a total of 15 LED OFF registers for the string of 12 LEDs. The address range used for these registers is 20h to 2Eh. Refer to Table 7 for complete list of LED OFF registers.
ADDR | REGISTER | D7 | D6 | D5 | D4 | D3 | D2 | D1 | D0 | DEFAULT |
---|---|---|---|---|---|---|---|---|---|---|
20h | LED1OFFL | LED1OFF[7:0] | 00000000 | |||||||
21h | LED2OFFL | LED2OFF[7:0] | 00000000 | |||||||
22h | LED3OFFL | LED3OFF[7:0] | 00000000 | |||||||
23h | LED4OFFL | LED4OFF[7:0] | 00000000 | |||||||
24h | LED1_4OFFH | LED4OFF[9:8] | LED3OFF[9:8] | LED2OFF[9:8] | LED1OFF[9:8] | 00000000 |
LEDxOFF[9:0] defines the count value within the 10-bit TCNT period when bypass switch x should be closed to turn LEDx off (x = 1 to 12). |
In the low address space starting at 00h that is defined above, all of the LEDxOFF registers follow all of the LEDxON registers. The higher address space starting at 40h maps the LEDxON and LEDxOFF pairs together so that the device requires a write of only 10 data bytes to update both the on and the off times for a given set of four LEDs. The registers that exist at addresses {40h-5Dh} are an alias for the registers that exist at addresses {0h-0Eh, 20h-2Eh}. In other words, a write to the register at address 00h affects the register contents at address 40h, and vice versa.
The ENABLE registers (ENON and ENOFF) determine whether a particular LEDxON or LEDxOFF value is enabled. In other words, an LED turns on only when TCNT reaches LEDxON if the corresponding ENON bit is set. Conversely, an LED turns off only when TCNT reaches LEDxOFF if the corresponding ENOFF bit is set. In this way, LEDs may be turned on fully, turned off fully, or modulated at a given duty cycle by programming the appropriate ENON and ENOFF register bits.
ADDR | REGISTER | D7 | D6 | D5 | D4 | D3 | D2 | D1 | D0 | DEFAULT |
---|---|---|---|---|---|---|---|---|---|---|
B0h | ENONL | ENON[8:1] | 00000000 | |||||||
B1h | ENONH | RESERVED | ENON[12:9] | 00000000 | ||||||
B2h | ENOFFL | ENOFF[8:1] | 00000000 | |||||||
B3h | ENOFFH | RESERVED | ENOFF[12:9] | 00000000 |
ENON[12:1] determine whether the device uses the corresponding LEDxON to turn on the LED. | ||
0 = Do nothing when TCNT = LEDxON 1 = Turn LED on when TCNT = LEDxON |
||
ENOFF[12:1] determine whether the device uses the corresponding LEDxOFF to turn off the LED. | ||
0 = Do nothing when TCNT = LEDxOFF 1 = Turn LED off when TCNT = LEDxOFF |
The control registers allow control and monitoring of several functions. The control registers occupy addresses C0h through C5h.
ADDR | REGISTER | D7 | D6 | D5 | D4 | D3 | D2 | D1 | D0 | DEFAULT |
---|---|---|---|---|---|---|---|---|---|---|
C0h | PCKDIV | RSVD | RSVD | DDEC[1:0] | RSVD | DPWR2[2:0] | 00000011 |
DPWR2[2:0]: This 3-bit value sets the power-of-2 divider for the incoming CLK signal before sending it to the decimal divider. Power-of-2 divider mapping: | |||
DPWR2[2:0] | Divide by: | ||
0 | 2 | ||
1 | 4 | ||
2 | 8 | ||
3 | 16 | ||
4 | 32 | ||
5 | 64 | ||
6 | reserved(1) | ||
7 | reserved(1) | ||
The default value of DPWR2 is 3. This sets the initial power-of-2 divider to divide-by-16 at reset. | |||
DDEC[1:0]: This 2-bit value sets the decimal divider for the internal signal coming from the power-of-2 divider. Decimal divider mapping: | |||
DDEC1:0] | Divide by: | ||
0 | 1 | ||
1 | 3 | ||
2 | 5 | ||
3 | reserved(1) | ||
The default value of DDEC is 0. This sets the initial decimal divider to divide-by-1 at reset. Using the two serially connected dividers in combination, clock dividers of various values are possible. | |||
(1) If any of the reserved values are written to DPWR2[2:0] or DDEC[1:0], the PWM clock divider is set to divide-by-16, regardless of any other settings. |
|||
PWM Clock Divider Examples:
DPWR2[2:0] = 0 DDEC[1:0] = 0 → PWM Clock = CLK / 2 |
|||
DPWR2[2:0] = 1 DDEC[1:0] = 2 → PWM Clock = CLK / 20 |
ADDR | REGISTER | D7 | D6 | D5 | D4 | D3 | D2 | D1 | D0 | DEFAULT |
---|---|---|---|---|---|---|---|---|---|---|
C1h | SYSCFG | RESERVED | CKWEN | CMWEN | SCMAST | PWR | 00000000 |
PWR: This bit is reset to 0 upon power-up or EN low. It may be written to a 1 by the micro-controller (MCU). Reading this bit allows the MCU to detect when there has been a power cycle. | ||||
0 = | A power cycle or EN low has occurred since last write to a ‘1’ | |||
1 = | No power cycle or EN low has occurred since the last write to a ‘1’ | |||
SCMAST: The Synchronization Master bit determines whether the TPS92661 device is a synchronization master or not. There should be only ONE Sync Master in the system. | ||||
0 = | Slave. A high input value on SYNC resets TCNT to 0. | |||
1 = | Master. The TPS92661 device generates a high pulse one CLK cycle long on SYNC when TCNT = 1023 and the PWM clock divider is about to roll over. SYNC may be connected to the next TPS92661 device in order to synchronize multiple TPS92661 devices with respect to each other. | |||
CMWEN: Communications Watchdog Timer Enable. | ||||
0 = | Communications watchdog timer disabled | |||
1 = | Communications watchdog timer enabled | |||
CKWEN: Clock Watchdog Timer Enable | ||||
0 = | Clock watchdog timer disabled | |||
1 = | Clock watchdog timer enabled |
ADDR | REGISTER | D7 | D6 | D5 | D4 | D3 | D2 | D1 | D0 | DEFAULT |
---|---|---|---|---|---|---|---|---|---|---|
C2h | DEFLEDL | DEFLED[8:1] | 00000000 | |||||||
C3h | DEFLEDH | RESERVED | DEFLED[12:9] | 00000000 |
DEFLED[12:1]: Default LED State register. This register determines which state to place the LED in when one of the watchdog timers times out. | ||||
0 = | LED off | |||
1 = | LED on |
ADDR | REGISTER | D7 | D6 | D5 | D4 | D3 | D2 | D1 | D0 | DEFAULT |
---|---|---|---|---|---|---|---|---|---|---|
C4h | TCNTL | TCNT[7:0] | 00000000 | |||||||
C5h | TCNTH | RESERVED | TCNT[9:8] | 00000000 |
TCNT[9:0]: This is the PWM period count value. The TCNT register automatically counts from 0 to 1023 and wraps. It is provided here with read/write access for diagnostic purposes. Writes to the TCNT register are loaded upon the next rising edge of CLK when there is a SYNC pulse present. |
The diagnostic registers hold the results of various faults and status flags for the system. The diagnostic registers exist in the address range E0h to E2h.
ADDR | REGISTER | D7 | D6 | D5 | D4 | D3 | D2 | D1 | D0 | DEFAULT |
---|---|---|---|---|---|---|---|---|---|---|
E0h | FAULTL | FAULT[8:1] | 00000000 | |||||||
E1h | FAULTH | RESERVED | FAULT[12:9] | 00000000 | ||||||
E2h | CERRCNT | CERRCNT[7:0] | 00000000 |
FAULT[12:1]: Fault Register | ||||
0 = | an LED fault has not occurred | |||
1 = | an LED fault has occurred | |||
The LED open and short fault detection circuitry is sampled just before the corresponding bypass switch is closed. If a fault exists at this time instant, a 1 is latched into the associated FAULT register bit. The FAULT register bits must be cleared manually by writing them back to 0. If an LED fault condition still exists at the next PWM period, the device immediately resets the corresponding FAULT register bit to a 1. Writing the FAULT register bits to 1 has no effect. | ||||
CERRCNT[7:0]: CRC Error Count Register | ||||
This register value is incremented each time a CRC error is received. This register may be read by the MCU and then written back to 0 to clear the count. The CERRCNT value saturates at FFh; it does not wrap back to 0 when it reaches FFh. The CERRCNT register is not automatically cleared when a communications reset is received. It must be cleared manually by writing it back to 0. Note that the CERRCNT register can be written to any 8-bit value. This is intended for diagnostic purposes. |
The pseudo-code below shows a pair of transactions: a write of the LEDOFF times for LEDs 1-4 followed by a read of the same registers (LED1OFF = 200, LED2OFF = 410, LED3OFF = 620, LED4OFF = 830).
tx_init (0x90) | Single device write of 5 bytes (Device ID = 0) |
tx_addr (0x20) | Register address = 0x20 (LED1OFFL) |
tx_data (0xc8) | LED1OFFL = Low_Byte (200) |
tx_data (0x9a) | LED2OFFL = Low_Byte (410) |
tx_data (0x6c) | LED3OFFL = Low_Byte (620) |
tx_data (0x3e) | LED4OFFL = Low_Byte (830) |
tx_data (0xe4) | LED1_4OFFH = High_Byte (830) << 6 |
High_Byte (620) << 4 | |
High_Byte (410) << 2 | |
High_Byte (200) | |
tx_crc1 (0x88) | CRC1 = Low_Byte (CRC-16-IBM) |
tx_crc2 (0x57) | CRC2 = High_Byte (CRC-16-IBM) |
tx_init (0xd0) | Single device read of 5 bytes (Device ID = 0) |
tx_addr (0x20) | Register address = 0x20 (LED1OFFL) |
tx_crc1 (0x5c) | CRC1 = Low_Byte (CRC-16-IBM) |
tx_crc2 (0x18) | CRC2 = High_Byte (CRC-16-IBM) |
rx_init (0x02) | Read Response, 5 data bytes to follow | |
rx_data (0xc8) | LED1OFFL = Low_Byte (200) | |
rx_data (0x9a) | LED2OFFL = Low_Byte (410) | |
rx_data (0x6c) | LED3OFFL = Low_Byte (620) | |
rx_data (0x3e) | LED4OFFL = Low_Byte (830) | |
rx_data (0xe4) | LED1_4OFFH = High_Byte (830) << 6 | |
High_Byte (620) << 4 | ||
High_Byte (410) << 2 | ||
High_Byte (200) | ||
rx_crc1 (0x78) | CRC1 = Low_Byte (CRC-16-IBM) | Must be reversed when read. See CRC Calculation Programming Examples section. |
rx_crc2 (0x3b) | CRC2 = High_Byte (CRC-16-IBM) |
As an additional example, the following pseudo-code shows a 2-byte write to TPS92661 Address 5, Register 0xB0 (ENON) with data of 0x55 to register 0xB0 and 0x05 to register 0xB1. Data sent (hex): 8D B0 55 05 D5 D8
tx_init (0x8D) | Single device write of 2 bytes (Device ID = 5) |
tx_addr (0xB0) | Register address = 0xB0 (ENON) |
tx_data (0x55) | ENONL = 0101 0101b |
tx_data (0x05) | ENONH = 0000 0101b |
tx_crc1 (0xD5) | CRC1 = Low Byte(CRC-16-IBM) |
tx_crc2 (0xD8) | CRC2 = High Byte(CRC-16-IBM) |
The UART waveform associated with the example in Table 6 is shown in Figure 33.
After this write had completed, the device enables all of the odd numbered LEDs (LED1, LED3, …, LED11) to turn on when TCNT = LEDxON register, while all of the even numbered LEDs remain off.
The C function below shows an example of how to generate the CRC bytes correctly for a transmission to the TPS92661 devices:
Uint16 crc_16_ibm(Uint8 *buf, Uint8 len)
{
Uint16 crc = 0;
Uint16 I;
while (len--){
crc ^= *buf++;
for (I = 0; I < 8; I++){
crc = (crc >> 1) ^ ((crc & 1) ? 0xa001 : 0);
}
}
return crc;
}
The CRC is transmitted LSByte first to/from the TPS92661 device.
Upon reading data from the TPS92661 device, the MCU should calculate and compare the CRC to determine whether valid data was received.
NOTE
The calculated CRC bytes must be bit-reversed before comparison to the received CRC bytes
bool is_crc_valid(Uint8 *rx_buf, Uint8 crc_start)
{
Uint16 crc_calc; // Calculated CRC
Uint8 crc_msb, crc_lsb; // Individual bytes of calculated CRC
// Calculate the CRC based on bytes received
crc_calc = crc_16_ibm(rx_buf, crc_start);
crc_lsb = (crc_calc & 0x00FF);
crc_msb = ((crc_calc >> 8) & 0x00FF);
// Perform the bit reversal within each byte
crc_msb = reverse_byte(crc_msb);
crc_lsb = reverse_byte(crc_lsb);
// Do they match?
if((*(rx_buf + crc_start) == crc_lsb) && (*(rx_buf + crc_start + 1) == crc_msb)){
return TRUE;
}
else{
return FALSE;
}
}
One way to perform the bit reversal is shown in the following C code:
Uint8 reverse_byte(Uint8 byte)
{
// First, swap the nibbles
byte = (((byte & 0xF0) >> 4)| | ((byte & 0x0F) << 4));
// Then, swap bit pairs
byte = (((byte & 0xCC) >> 2) | ((byte & 0x33) << 2));
// Finally, swap adjacent bits
byte = (((byte & 0xAA) >> 1) | ((byte & 0x55) << 1));
// We should now be reversed (bit 0 <--> bit 7, bit 1 <--> bit 6, etc.)
return byte;
The C functions below show examples of how to code a single register write and single register read. It is recommended that the user get this code running first and then expand to some of the other commands and multi-byte reads and writes.
Write Example:
void lmm_wr_1_reg(Uint8 lmm, Uint8 regaddr, Uint8 data)
{
Uint8 TxBuf[5];
Uint16 I;
// We must first assemble the bytes and CRC them
TxBuf[0] = (0x80 | lmm);
TxBuf[1] = regaddr;
TxBuf[2] = data;
// Get the CRC back
I = crc_16_ibm(TxBuf, 3);
// Process and store bytes
TxBuf[3] = (I & 0x00FF); // LSByte
TxBuf[4] = ((I >> 8 & 0x00FF); // MSByte
/* INSERT MCU-SPECIFIC UART CODE HERE */
// Now we can send it to the matrix network
for(I = 0; I < 5; I++){
lmm_uart_xmit(TxBuf[i]);
}
}
Read Example:
Uint8 lmm_rd_1_reg(Uint8 lmm, Uint8 regaddr)
{
/* DATA WILL BE AVAILABLE IN RxBuf ON RETURN */
Uint8 TxBuf[4];
Uint16 I;
// We must first assemble the request and CRC it
TxBuf[0] = (0xC0 | lmm);
TxBuf[1] = regaddr;
// Get the CRC back
I = crc_16_ibm(TxBuf, 2);
// Process and store bytes
TxBuf[2] = (I & 0x00FF); // LSByte
TxBuf[3] = ((I >> 8) & 0x00FF); // MSByte
// Also make sure we are prepared to receive the data from the LMM
ReturnBytes = 1+1+2; // This is the number of bytes we expect to get back
/* 1 Response Frame Init + 1 Data + 2 CRC */
GatheredBytes = 0;
/* INSERT MCU-SPECIFIC UART CODE HERE */
// Now we can send it to the matrix network
for(I = 0; I < 4; I++){
lmm_uart_xmit(TxBuf[i]);
}
/* INSERT MCU-SPECIFIC UART CODE HERE */
// Now we can send the request to the matrix network
// This is basically pseudo-code for however your MCU receive works
while(GatheredBytes != 4);
// Check the CRC (should be in RxBuf[2] and [3])
if(is_crc_valid(RxBuf, 2)){
return TRUE;
}
else{
return FALSE;}
}
ADDR | REGISTER | D7 | D6 | D5 | D4 | D3 | D2 | D1 | D0 | DEFAULT |
---|---|---|---|---|---|---|---|---|---|---|
LED ON REGISTERS | ||||||||||
00h | LED1ONL | LED1ON[7:0] | 00000000 | |||||||
01h | LED2ONL | LED2ON[7:0] | 00000000 | |||||||
02h | LED3ONL | LED3ON[7:0] | 00000000 | |||||||
03h | LED4ONL | LED4ON[7:0] | 00000000 | |||||||
04h | LED1_4ONH | LED4ON[9:8] | LED3ON[9:8] | LED2ON[9:8] | LED1ON[9:8] | 00000000 | ||||
05h | LED5ONL | LED5ON[7:0] | 00000000 | |||||||
06h | LED6ONL | LED6ON[7:0] | 00000000 | |||||||
07h | LED7ONL | LED7ON[7:0] | 00000000 | |||||||
08h | LED8ONL | LED8ON[7:0] | 00000000 | |||||||
09h | LED5_8ONH | LED8ON[9:8] | LED7ON[9:8] | LED6ON[9:8] | LED5ON[9:8] | 00000000 | ||||
0Ah | LED9ONL | LED9ON[7:0] | 00000000 | |||||||
0Bh | LED10ONL | LED10ON[7:0] | 00000000 | |||||||
0Ch | LED11ONL | LED11ON[7:0] | 00000000 | |||||||
0Dh | LED12ONL | LED12ON[7:0] | 00000000 | |||||||
0Eh | LED9_12ONH | LED12ON[9:8] | LED11ON[9:8] | LED10ON[9:8] | LED9ON[9:8] | 00000000 | ||||
LED OFF REGISTERS | ||||||||||
20h | LED1OFFL | LED1OFF[7:0] | 00000000 | |||||||
21h | LED2OFFL | LED2OFF[7:0] | 00000000 | |||||||
22h | LED3OFFL | LED3OFF[7:0] | 00000000 | |||||||
23h | LED4OFFL | LED4OFF[7:0] | 00000000 | |||||||
24h | LED1_4OFFH | LED4OFF[9:8] | LED3OFF[9:8] | LED2OFF[9:8] | LED1OFF[9:8] | 00000000 | ||||
25h | LED5OFFL | LED5OFF[7:0] | 00000000 | |||||||
26h | LED6OFFL | LED6OFF[7:0] | 00000000 | |||||||
27h | LED7OFFL | LED7OFF[7:0] | 00000000 | |||||||
28h | LED8OFFL | LED8OFF[7:0] | 00000000 | |||||||
29h | LED5_8OFFH | LED8OFF[9:8] | LED7OFF[9:8] | LED6OFF[9:8] | LED5OFF[9:8] | 00000000 | ||||
2Ah | LED9OFFL | LED9OFF[7:0] | 00000000 | |||||||
2Bh | LED10OFFL | LED10OFF[7:0] | 00000000 | |||||||
2Ch | LED11OFFL | LED11OFF[7:0] | 00000000 | |||||||
2Dh | LED12OFFL | LED12OFF[7:0] | 00000000 | |||||||
2Eh | LED9_12OFFH | LED12OFF[9:8] | LED11OFF[9:8] | LED10OFF[9:8] | LED9OFF[9:8] | 00000000 | ||||
LED ONOFF REGISTERS (Remapped LED ON and LED OFF Registers) | ||||||||||
40h | LED1ONL | LED1ON[7:0] | 00000000 | |||||||
41h | LED2ONL | LED2ON[7:0] | 00000000 | |||||||
42h | LED3ONL | LED3ON[7:0] | 00000000 | |||||||
43h | LED4ONL | LED4ON[7:0] | 00000000 | |||||||
44h | LED1_4ONH | LED4ON[9:8] | LED3ON[9:8] | LED2ON[9:8] | LED1ON[9:8] | 00000000 | ||||
45h | LED1OFFL | LED1OFF[7:0] | 00000000 | |||||||
46h | LED2OFFL | LED2OFF[7:0] | 00000000 | |||||||
47h | LED3OFFL | LED3OFF[7:0] | 00000000 | |||||||
48h | LED4OFFL | LED4OFF[7:0] | 00000000 | |||||||
49h | LED1_4OFFH | LED4OFF[9:8] | LED3OFF[9:8] | LED2OFF[9:8] | LED1OFF[9:8] | 00000000 | ||||
4Ah | LED5ONL | LED5ON[7:0] | 00000000 | |||||||
4Bh | LED6ONL | LED6ON[7:0] | 00000000 | |||||||
4Ch | LED7ONL | LED7ON[7:0] | 00000000 | |||||||
4Dh | LED8ONL | LED8ON[7:0] | 00000000 | |||||||
4Eh | LED5_8ONH | LED8ON[9:8] | LED7ON[9:8] | LED6ON[9:8] | LED5ON[9:8] | 00000000 | ||||
4Fh | LED5OFFL | LED5OFF[7:0] | 00000000 | |||||||
50h | LED6OFFL | LED6OFF[7:0] | 00000000 | |||||||
51h | LED7OFFL | LED7OFF[7:0] | 00000000 | |||||||
52h | LED8OFFL | LED8OFF[7:0] | 00000000 | |||||||
53h | LED5_8OFFH | LED8OFF[9:8] | LED7OFF[9:8] | LED6OFF[9:8] | LED5OFF[9:8] | 00000000 | ||||
54h | LED9ONL | LED9ON[7:0] | 00000000 | |||||||
55h | LED10ONL | LED10ON[7:0] | 00000000 | |||||||
56h | LED11ONL | LED11ON[7:0] | 00000000 | |||||||
57h | LED12ONL | LED12ON[7:0] | 00000000 | |||||||
58h | LED9_12ONH | LED12ON[9:8] | LED11ON[9:8] | LED10ON[9:8] | LED9ON[9:8] | 00000000 | ||||
59h | LED9OFFL | LED9OFF[7:0] | 00000000 | |||||||
5Ah | LED10OFFL | LED10OFF[7:0] | 00000000 | |||||||
5Bh | LED11OFFL | LED11OFF[7:0] | 00000000 | |||||||
5Ch | LED12OFFL | LED12OFF[7:0] | 00000000 | |||||||
5Dh | LED9_12OFFH | LED12OFF[9:8] | LED11OFF[9:8] | LED10OFF[9:8] | LED9OFF[9:8] | 00000000 | ||||
ENABLE REGISTERS | ||||||||||
B0h | ENONL | ENON[8:1] | 00000000 | |||||||
B1h | ENONH | RESERVED | ENON[12:9] | 00000000 | ||||||
B2h | ENOFFL | ENOFF[8:1] | 00000000 | |||||||
B3h | ENOFFH | RESERVED | ENOFF[12:9] | 00000000 | ||||||
CONTROL REGISTERS | ||||||||||
C0h | PCKDIV | RSVD | RSVD | DDEC[1:0] | RSVD | DPWR2[2:0] | 00000011 | |||
C1h | SYSCFG | RESERVED | CKWEN | CMWEN | SCMAST | PWR | 00000000 | |||
C2h | DEFLEDL | DEFLED[8:1] | 00000000 | |||||||
C3h | DEFLEDH | RESERVED | DEFLED[12:9] | 00000000 | ||||||
C4h | TCNTL | TCNT[7:0] | 00000000 | |||||||
C5h | TCNTH | RESERVED | TCNT[9:8] | 00000000 | ||||||
DIAGNOSTIC REGISTERS | ||||||||||
E0h | FAULTL | FAULT[8:1] | 00000000 | |||||||
E1h | FAULTH | RESERVED | FAULT[12:9] | 00000000 | ||||||
E2h | CERRCNT | CERRCNT[7:0] | 00000000 |