BQ79616-Q1: High Current Draw during auto-addressing and Comm Clear after auto-addressing Stack Reads

Hello Colin,

Yes this is quite odd. It sounds like a potential setup issue. 
Are you using a USB2ANY and the GUI to communicate?
Or are you using an FTDI or something and your own custom script?

What is the normal baseline current, and what is the maximum current draw?

Is the current draw occurring on a particular BQ79616 device? If you only use 1x 600 and 1x 616, does it still occur? 

Have you been able to communicate with the BQ79600 device and if so how?

To continue debug, we may have to look at bench setup and potentially put a logic analyzer on the comm lines to see what is going on. 
Also be sure all your SPI lines are connected to the BQ79600 correctly.

Finally, please provide me with your pseudo code and try to determine if there is a specific command that leads to this. 

Best,

     Quentin

Quentin,

I'm not currently using a USB2ANY or a GUI to communicate, the BQ79616s and BQ79600 are on the same board as the main processor.
We have a couple of BQ79616 eval boards but no 79600 eval board.

The BQ79616s are powered through a separate power supply from the rest of the board, both BQ79616s are hooked up to the supply so I can't run the current setup with one 616 powered.
The 600 is powered by the board's power supply.

Current draw for the two 616s is 6mA before waking them up, 24mA when running in active mode, and 58-60mA in the high current mode.
If I current-limit the chips to prevent them from getting 58-60mA current draw, it drops down to 27mA after hitting the limit.
Voltage is limited to 26V.

I worked with someone on the hardware team this morning, he said both 616s look like they're pulling in more power than normal in the 58-60mA state but one of the 616s is drawing more power than the other.
He also found a couple points on the board to probe the communication between the 616s, he said the communications look healthy but they keep sending out some 200ns and 400ns pulses between each other in the high-current state.
I think it was 3 short pulses, 2 long pulses, and 2 short pulses before a break, I'd have to get another scope capture to confirm.

I've been able to communicate with the BQ79600, I confirmed this through a toggleable test procedure that sends the following read and write messages to the 79600 before sending a wake to the 79616s:

- Read from register 0x2001, confirm main processor receives 0x14 as data (default value)
- Write to register 0x2001 to change it to 0x1C
- Read from register 0x2001, confirm main processor receives 0x1C as data
- Write to register 0x2001 to change it to 0x14
- Read from register 0x2001, confirm main processor receives 0x14 as data

Most of the procedure is me packing data into a SPI transfer that gets sent from the main processor's SPI buffer register, top 16 bits are SPI settings while the bottom 16 bits are the transmitted data.

Here's a psuedocode example with a Single Read packet to the 79600's 0x2001 register:

SingleReadStruct.INIT = 0x80
SingleReadStruct.DEV_ADR = 0x00
SingleReadStruct.REG_ADR = 0x2001
SingleReadStruct.READ_SIZE = 0x00
SingleReadStruct.CRC = 0x0000

GetSpiCRC(SingleReadStruct.rawBytes, 7) // takes in packet read as raw bytes and # of bytes in packet, returns CRC in SingleReadStruct.CRC field

spi_tx_buf[0] = HOLD_CS_SPI_SETTING << 16
spi_tx_buf[0] = SingleReadStruct.INIT << 8
spi_tx_buf[0] = SingleReadStruct.DEV_ADR

spi_tx_buf[1] = HOLD_CS_SPI_SETTING << 16
spi_tx_buf[1] = SingleReadStruct.REG_ADR // 16-bit field

spi_tx_buf[2] = HOLD_CS_SPI_SETTING << 16
spi_tx_buf[2] = SingleReadStruct.READ_SIZE << 8
spi_tx_buf[2] = SingleReadStruct.HighCRCByte

spi_tx_buf[3] = SEND_1BYTE_EOQ_SETTING << 16
spi_tx_buf[3] = SingleReadStruct.LowCRCByte

while(SPI_RDY == 0)
{
    // Wait for SPI_RDY to go high
}

SendSPIPkt(SPI_Ch_A, spi_tx_buf, spi_rx_buf, 4) // Discard RX Buffer data for this transaction

Comm_Clear_Timeout(SINGLE_READ, 7) // Sends Comm Clear if SPI_RDY stays low longer than expected

I have an oscilloscope hooked up to the MOSI/MISO/CS/SCLK signals on the 79600 to view communication between the bridge and main processor.

Hope that answers your questions, let me know if you need more information.

-Colin

Colin,

Can you share me your schematic?
Also how many boards do you have printed? 
Do they all have this issue?

Best,

     Quentin

Quentin,

I can't share the schematics here, we'd have to arrange something through e-mail or a secure file transfer.

We have at least 3 boards, I tried the startup procedure on a different board and saw the same high-current state during auto-addressing.

A couple days ago I tried communicating with one of the 616 chips after DLL Sync Broadcast writes since its default address was listed as 0x1. I got a response that matches what I'd expect from a 616 (address register was 0x1, VMB_DONE_THRESH matched it's reset value of 0x3F), but the board goes into its high current state soon after sending the read packet. Not sure if that narrows down what's causing the 60mA current draw, but the processor can communicate with one of the 616s using the 600.

I also ran auto-addressing and some read packets today on a modded board that stopped communication with the second 79616, leaving the setup with a 79600 (default address 0) and one 79616 (default address 1). I didn't see any increased power draw or SPI_RDY staying at 0, and was getting good data back from the 600 and 616. I had to fix one issue with how I was handing responses from a Stack Read, once I resolved that the auto-address procedure seemed to work fine. The 1 616 setup still had a Shutdown state power draw of 6mA and a normal operating power draw of 24mA.

-Colin