BQ76942: Communication/Reset Issue

Hello Nicolai,

Nicolai Sawilla said:

Apparently this causes the I2C interface of the BQ to lock up because it will never again ACK any command

What do you mean by the device will lock up? Is the AFE holding the SCL low? Have you tried sending 8+1 clock pulses? This previous forum post may be able to assist you: How to Inform an I2C Target to Release the Bus.

Nicolai Sawilla said:

So I try to send it a RESET_PASSQ subcommand as well but that is without effect unless I insert a 300ms delay between RST_SHUT going low again an the subcommand being sent.
What is going on here, why is this delay needed and where is it documented?

A full reset signal can take up to ~500ms, whereas a partial reset can take up to ~200-300ms. This is not documented at the moment.

Nicolai Sawilla said:

Why does the OTP_WR_CHECK subcommand take up to 200ms to execute?

The timing of subcommands can vary depending on system operation at the time. I have seen users wait 10ms to 100ms just to be safe in giving the AFE enough time to process the command and update its register with the correct values. 

Nicolai Sawilla said:

, 0x3e and 0x3f always returning 0xff, why is that?

Usually 0xFF means the subcommand has not completed operation yet. This can usually occur when you’re reading the data too quickly especially after writing to it. Try adding a 2 ms wait time/delay in between measurements. Section 2 Subcommands from the BQ769x2 Software Development Guide and/or Section 3.1 Direct Commands and Subcommands can provide more information regarding it.

Nicolai Sawilla said:

And why is a "CRC" appended to every byte?

CRC is optional for our device as some users do not want CRC. Section 9.1 Serial Communications Overview from the Technical Reference Manual gives more information regarding the part’s different communication type settings.

Best Regards,
Alexis

Thank you for your response!

Alexis_H said:

What do you mean by the device will lock up? Is the AFE holding the SCL low? Have you tried sending 8+1 clock pulses? This previous forum post may be able to assist you: How to Inform an I2C Target to Release the Bus.

The device does not respond to any commands at all, it does not respond with an ACK after the MCU sends its address. I tried sending clock pulses, 9 or even more, without any effect.

Alexis_H said:

The timing of subcommands can vary depending on system operation at the time. I have seen users wait 10ms to 100ms just to be safe in giving the AFE enough time to process the command and update its register with the correct values. 

Is there no way to check if a write-subcommand has completed execution?

Alexis_H said:

Usually 0xFF means the subcommand has not completed operation yet. This can usually occur when you’re reading the data too quickly especially after writing to it. Try adding a 2 ms wait time/delay in between measurements.

Since some commands needed more time than documented, the simple approach with a constant delay of 2ms did not work reliable enough for me, so I implemented the method of checking 0x3e and 0x3f before reading the remaining data. But the subcommand 0x0084 only ever returns 0xff for at least 1s, longer wait times are unacceptable for my application because of a watchdog. The TRM does not mention that a delay in the read-0x3e-0x3f-loop is needed?

Alexis_H said:

CRC is optional for our device as some users do not want CRC.

I know the "CRC" is optional but it is not very useful. The purpose of a CRC is to detect corruption in a block of data with a single hash-like checksum. The way it is implemented here, a CRC byte is sent for every data byte, doubling the necessary bandwidth on the bus, which is no more useful than sending every byte twice. And it could instead have been accomplished with a single, properly implemented CRC byte.

Best Regards
Nico

Hello Nico,

Nicolai Sawilla said:

The device does not respond to any commands at all, it does not respond with an ACK after the MCU sends its address. I tried sending clock pulses, 9 or even more, without any effect.

This What is the I2C Device Address of the BQ769x2 Family FAQ may help potentially.

Nicolai Sawilla said:

Is there no way to check if a write-subcommand has completed execution?

The wait time is the simplest approach. Another approach for subcommands is described in Section 3.1 Direct Commands and Subcommands of the technical reference manual which checks if the subcommand has completed operation or not. You could keep reading 0x3E/0x3F until it returns what originally written or incorporate a retry scheme. 

This Software Development Guide may also be useful to refer too.

Nicolai Sawilla said:

But the subcommand 0x0084 only ever returns 0xff for at least 1s

Writing to the subcommand 0x0084 CB_SET_LVL() shouldn't require a delay as there isn't any data to fetch. The timing/delay should only be needed when reading to fetch data.

Are you following the subcommand with a write to 0x60/0x61 with the checksum/length as well as doing this when in CONFIG_UPDATE mode? Section 3 Reading and Writing RAM Registers from the Software Development Guide explains this a bit more. 

Nicolai Sawilla said:

The purpose of a CRC is to detect corruption in a block of data with a single hash-like checksum

With certain commands you can do a block read, instead of reading each individual byte. Because the voltage measurement commands are in ascending order, you can use the direct command to read starting from Cell 1 voltage (0x14) and read 32 bytes from there to read all 16 Cell Voltages if you wanted to have only those values.

Another example/method to potentially read all the cell voltage measurements with less commands are with the block subcommands that section in the TRM briefly talks about. The sections after Section 4.4 give more detail regarding it.

Best Regards,
Alexis