BQ76952EVM: slow response to subcommand (0x0071)

Hi Eduardas,

Sorry for the late reply. I am out of office recently.

Can you follow below approach for subcommand reading?

BRs

Kian

This is what I do as written in the instructions, only in the third step I read 32 bytes instead of 2. I tried to pause between the second and third steps, the result was identical.

Battery Management Studio ( bqStudio ) Version : 1.3.127 Build 3:

BqStudio's response to the 0x71 command comes after ~16ms.

Hi Eduardas,

If you read 32bytes, the duration will be much longer than 2 bytes reading. The AFE will stretch the clock line when it is busy so the block read will take more time than 2 bytes.

BRs

Kian 

BQstudio add very long fix delay to read the subcommand. You don't have to refer it.

The result is same, answer is after 4.81ms.

Hi Eduardas,

4ms makes more sense. Sometimes, it does need that long time. It depends on the tasks loading the device having when reading the subcommand. If you read more times, you should observe a shorter response time.

BRs

Kian

The document bq76952 Technical Reference Manual states
that the response should come within 660us, I get it within 4.7 ms, i.e. ~7 times slower. And your response is "make senese"? Is this a joke?

What do I need to do to get an answer within 660us?

Hello Eduardas,

As Kian stated above, the timing can depend on the tasks the device is loading when reading the subcommand. I have seen users add up to 10ms as shown in this previous post for subcommands. 

Table 9-2. Command/Subcommand Operation Time from the TRM states an approximate time required to complete an operation based on the command/subcommand. These are only approximate and can vary depending on system operation and time. We usually recommend a host processor incorporate a retry scheme to handle communication errors or delays that occur during operation. 

Another approach instead of just adding a delay is to read the 0x3E/0x3F until the subcommand indicates it has completed operation. When the subcommand has completed, the readback returns what was originally written instead of 0xFF. This only applies to subcommands that return data to be read back. More information regarding this approach can be found in Section 3.1 Direct Commands and Subcommands of the TRM. 

Best Regards,
Alexis