Manufacturer Block Access (0x44) in BQ40Z50 can't be read

Hi Prakash,

Can you help me to confirm are you using the BQ40Z50 or the BQ40Z50-R1? Also please make sure your device is unsealed and in full access mode.
To help solve this issue, can you send me a screenshot of BQStudio showing how you are sending the command to the device?

Best,

Justin

Hi,

I have been using Bq40Z50 only. I have tried to read the chemical ID as per the explanation given in the TRM section 12.1. I have attached the screen shot of the error meesage which i got from BQstudio.

Thanks in advanceManufacturerBlockAccess.docx

Hi Prakash,

I have reproduced your error by typing "0600" in the Block section.  Can you please try to add a space inbetween like this: "06 00"?

By doing this, I was able to get a success. After this, type the "44" command in the read section, and in the block you will see "06 00 XX YY" where XX YY will be your chemid returned in Little Endian. So the actual chemid will be YYXX.

Best,

Justin

Hi Justin,

Thanks for your reply. As per the procedure explained by you its working fine. But while sending this command some extra bytes also sending to battery. I have captured them using logic analyzer. For example if I want read the operation Status register

1. SMBus block write. Command = 0x44. Data sent = 54 00. But the transmitted data is "0x44 0x02 0x54 0x00 0x34" In this I am not able understand the reason for why the bytes 0x02 and 0x34 is sent. Since the procedure explained in the TRM section 12.1 is not explained anything about these bytes. Not only for this operationstatus even when I am trying to read the permanentfailure status also like these bytes are transmitting. Could you please explain why these extra bytes sending or is the TRM yet to be updated? I am using SLUUA43–December 2013 TRM.

2. SMBus block read. Command = 0x44. Data read = 0x16 0x44 0x17 0x06 0x54 0x00 0x87 0x01 0x00 0x00 0xEA. The expected byte for this operationstatus is 4 bytes only. Why these extra bytes are receiving?

Thanks In Advance

Hi Prakash,

As far as those extra bytes are concerned, I have been able to reproduce your set up, and I also see the extra 0x02 and 0x34 being transmitted. The reason for this is related to our communication process, and does not mean that your actual command is not being transmitted.

I have used BQstudio, not a host processor, to transmit the same command (and even other commands), and I also see the data you are referring to. Nonetheless, the transmission was successful.

Best,
Justin

Hi Justin,

I have tried to communicate using host processor (MSP430F5338), but if I have send command as per the format which is explained in TRM not able to get the proper values from battery. But if I tried as per the format which I was explained early (See the logic Analyzer output) I can get the correct value. If possible could you please check this from your end and help me. 

Thanks in advance.

Hi Justin,

Any updates on this please let me know

Hi Prakash,

Can you please explain a little more so I can understand your problem more clearly?

1. Did you obtain the logic analyzer output by sending commands via BQstudio or from your MSP host processor?
2. Please detail what procedure you are following from the TRM. Specifically, what format are you using to get the incorrect values from the battery?
3. Please detail the procedure you are using to get the successful logic analyzer output. Which different format are you using to get a successful send that is different from what you have read in the TRM?

Best,
Justin

Hi Justin,

Please find my responses below

1. The attached logic analyzer output is taken while communicating with battery via bqstudio.

2. I have followed the procedure given in section 12.1 of TRM via communicationg MSP430 to battery.

3. I have used the following procedure while communicating MSP430 with battery (these format is not given in the section 12.1) 

0x0b -> battery address

0x0b 0x44 0x02 0x54 0x00 -> i2c write
0x0b 0x44 -> i2c read

i can get the proper data.

Though this format is i2c protocol format my question why the 0x02 is required during i2c write?

Hi Justin,

Please find my responses below

1. The attached logic analyzer output is taken while communicating with battery via bqstudio.

2. I have followed the procedure given in section 12.1 of TRM via communicationg MSP430 to battery.

3. I have used the following procedure

0x0b -> battery address

0x0b 0x44 0x02 0x54 0x00 -> i2c write
0x0b 0x44 -> i2c read

i can get the proper data.
Thogh these formats are i2c protocol, my question is why 0x02 is required here and why this is not explained in TRM?

Hi Prakash,

0x02 is the length of bytes (block writes require length), and 0x34 is PEC byte. bqStudio uses PEC control, either MSP430 should have PEC control implemented or PEC byte may be ignored.

To learn more about the SMBus protocol, please check out the attached file:

SMBus made simple v6 (2).pdf

Best,

Justin

Hi, Prakash,

I follow your step with iic commands, I cannot read correct value from bq40z50.

Can you provide code ?