BQ76PL455A-Q1: BQ76PL455A stack communication issue, excess bytes in response

Hi Mislav,

Thanks for the question! This could be because you may be reading from registers that send back 4 bytes instead of 2. For example, check the datasheet section 7.6.3.3 and check for the CMD_REFSEL. This bit sends out 4 bytes because it measures 4.5V and then the gnd. Please check what registers you are reading from and if this is not the case please send your hex commands and response frames.

Best Regards,

Taylor

Thank you for the quick reply. My hex command is 85 01 02 20 FF FF FF 00 19 6E. One of expected response frames is 2F AA A8 AA DD AA C3 AA D5 AA C0 AA D2 AA D4 AA BD AA E0 AA CB AA EB AA CD AA D0 AA D4 AA CC AA D9 95 7D 94 99 95 19 95 8D 95 89 95 59 95 51 95 61 80 B1. In the three images below you can see the frame recorded by a scope.

That was the expected frame. As I mentioned, sometimes the response frame contains four more bytes of zeros. The command frame is the same, the response frame was now 33 AA C0 AA B9 AA D3 AA C1 AA DC AA CA AA D8 AA C5 AA E0 AA DB AA CB AA ED AA BC AA E8 AA D0 AA C9 95 7D 94 9D 95 15 95 89 95 8D 95 55 95 51 95 5D 00 00 00 00 55 74. The following three images show the frame.

Can you tell what is the cause of this?

Mislav Blajic

Hi Blajic,

Can you show me your register settings of 0X03-06?

Roger

Hi Roger, sorry for the late reply. First I send the write without response command for both boards to sample channels, register 0x03-06 is set to values are 0xFF FF FF C0. Then I read the channels from the first board, sending to register 0x03-06 values 0xFF FF FF 00. After reading from the first board, I send the same command to the second board (only changing the board adress), meaning register 0x03-06 values are again 0xFF FF FF 00.

Mislav

Hi Blajic,

I am bit confused.

You are changing 0x03 to 0XFF FF FF C0 to 0XFF FF FF 00 to both boards.

Is there a reason why you doing this?

Default setting is 0XFFFF0000.

If you do any POR or comm time out  then it goes back to default setting 0xFFFF0000.

Please double check and make sure you don't do that.

Roger

Hi Roger,
to clarify:
- we are using two EVMbq76pll455 boards daisy-chained to read voltages from 32 batteries, sampling is periodic (about 1 second between each request)
- we have no communication issues or excessive bytes when using the same communication commands using only one board, the only difference being the address of the device.

To clarify on communication commands to bq76pl455a :
-please refer to "bq76pl455a-q1 Software Design Reference" point 4.3.1. and 4.3.2 :
1 . We are sending sync sample request including channel selection for sampling (0xFF FF FF C0 - meaning to sample 16 battery channels + 8 aux channels + digital and analog temps) -
2. Second command reads prevoiusly sampled data from the board using READ SAMPLED VALUES COMMAND including the data we wish to read (0xFF FF FF 00 - meaning to read 16 battery channels + 8 aux channels, omitting analog and digital temps).

We have no POR or communication timeout issues.

Please explain how come that the same command request to bq76pll455a does not always reproduce the same response, physical communication problems are out of question because the CRC (last two bytes) of the message response is correctly calculated with null-bytes included in CRC calculation. Also, why does the same command request reproduce identical response when using only one board?
Could you please try to recreate the scenario and check for same problems?

Best regards,
Mislav

Hi Roger,
We have tried initializing the register with 0xFF FF FF 00 and not changing it later, now it works as expected. Thank you. So, what we have concluded is that the 0x03 register values are supposed to be changed only when sampling, not when just reading. I think it should be clearly stated in the datasheet.

Best regards,
Mislav