BQ79612-Q1: BQ79612-Q1 HW_Reset of Individual Module Prevents Read Operations

Hello,

During the debugging of our BQ79612 stack host, warm resets will routinely generate an accidental HW_RESET ping as a result of the default pull direction of the host's UART TX line. The following events will take place in this scenario:

1. Host UART Tx (BQ Rx) line is high.
2. User triggers a warm reset via an external button. Execution is halted. The default pull direction of the host UART Tx line is low.
3. User restarts execution ~2 seconds later, with the host UART Tx line being pulled back high via firmware configuration as part of the host initialization routine.

In the above scenario, a HI-LO-HI signal is seen on the first BQ node with a LO time of 2 seconds, triggering a HW_RESET. This is confirmed by observing the current supplied to the base BQ node.

For the purposes of this discussion, assume there are 2 BQ nodes in the stack. After the HW_RESET is triggered on the base BQ node, independent of the state of the second BQ node (previously initialized or following a POR event), broadcast reads do not respond with data following a stack re-initialization. Any broadcast reads will timeout, with no data observed on the base BQ Tx line.

The initialization sequence involves a WAKE ping, followed by a sequence of commands identical to what is described within Table 9-19 of the TRM (including both the dummy read and dummy write operations). Additionally, a delay greater than tHWRST exists between the HW_RESET and WAKE pings. Note that the initialization sequence works as intended if the HW_RESET ping is never delivered, as is the case when not debugging.

A couple of other observations were noted while investigating:

• If, between the base BQ node HW_RESET event and the initialization sequence, an identical POR event is subjected to both BQ nodes (i.e disconnecting and reconnecting the battery stack), the initialization sequence is successful.
• If the BQ stack is reconfigured to only include the base device (i.e. removing the second BQ node in this scenario), the initialization sequence is successful.
• Broadcast writes remain operational. This is confirmed by writing a timeout configuration and observing both BQ nodes enter the SHUTDOWN state following this delay in the absence of additional comms.

Are there any unintended consequences of the HW_RESET event that would explain the behaviour described above?

Thanks in advance.

Grayson