BQ27545-G1: retrieve control command data failed

hi

For the  connections to bqstudio, make sure the pins are correctly connected for the hdq port on the e2400.  if you are able to get bqstudio to work, use the below tool to sniff the bus to understand what it is you are doing wrong.

HDQSniffer_1.00_Software.zip

thanks

Onyx

Hi Guys,

I can't get bqstudio to work, is there any tip for that? and is there any guide line on get ev2400 and bqstudio to work?

Could you please check the pictures i attached in original post? if there is abnormal?

Thanks
Liberty

Hi Onyx,

thanks for reply.

Yes, I have one EV2400, refer to the picture. is this enough for debugging?

Thanks
Liberty

Hi Onyx,

Thanks for the quick response.

Let me tell the whole story, device CN51 is our very old product which using bq27545-G1 for our battery and interface is HDQ. Now we have request to do some calibration to the battery, I'm implementing this feature, but met issues.

Issue is I can't read control command result from gauge after write control command, but I can read other commands successfully. just control command fails. Then I found that the original driver already have issue with retrieve control command result.

I guess the issue is in HDQ protocol part, but lacking of experience to investigate, so I request TI's help. TI's suggestion is to buy one EV2400 for debugging.

Then you know the rest story, I can't connect EV2400 successfully between PC and battery, and request further help.

Could you please give advice based on above history? 

Thanks

Liberty

Hi Onyx,

Thanks for your reply, I have few more questions:

for Communicate with bqstudio, I want to confirm my connection are correct, Currently I connect VSS and SDA from HDQ port on EV2400, is this enough? I also tried to connect VSS of HDQ port to battery's Positive pin, is this correct to pull up EV2400, or I need apply extern 3.3V to HDQ of EV2400?

and for our android terminal HDQ communication fails, for normal command, OS send one byte and then read result from gauge, but for control command, it need send 2 bytes in sequence, then read result, I guess that's the problem, I doubt HDQ driver didn't take care of this 2 bytes sending correct, then caused issue, but I didn't have experience on HDQ protocal (I did some modify but don't fix the issue), is there any document or guide line on HDQ android driver? Maybe HDQ driver already udpated but I don't know, do you know where can I find reference HDQ driver?

Thanks a lot for your help.
Liberty

Hi Onyx,

I reviewed my code again, and about send command part, could you please check if below sequence are correct?

for example, we want to read CHEM_ID from gauge:
//CHEM_ID 0x0008
//CONTROL_STATUS 0x0000
//Control() CNTL 0x00/0x01
#define BQ27545_CONTROL_LO 0x00
#define BQ27545_CONTROL_HI 0x01

//indicate which command we need access
w1_bq27000_write(dev, 0x08, BQ27545_CONTROL_LO);
w1_bq27000_write(dev, 0x00, BQ27545_CONTROL_HI);

//read result
bq27x00_read(di, BQ27545_CONTROL_HI, false);

Is above process have problem?

Thanks
Liberty

Hi Dominik,

Thanks a lot, I think we made big progress, now I can get correct control cmd result.

now I have bad lucky on unsealing battery, after I send unseal key to battery, the battery still sealed - checked control status.

Could you please check if below codes to unseal battery are correct? At first I guess I use wrong key sending sequence but still failed with different sequence. and I also tried with different batteries, not a single unit fail.

for example, unseal key is: 0x12345678

//show control status before unseal
w1_bq27000_write(dev, 0x00, BQ27545_CONTROL_LO);
w1_bq27000_write(dev, 0x00, BQ27545_CONTROL_HI);
read = bq27x00_read(di, BQ27545_CONTROL_LO, false);
pr_err("LibertyAdd: before unseal, control: 0x%x\n", read);

//send unseal key
w1_bq27000_write(dev, 0x34, BQ27545_CONTROL_LO);
w1_bq27000_write(dev, 0x12, BQ27545_CONTROL_HI);

w1_bq27000_write(dev, 0x78, BQ27545_CONTROL_LO);
w1_bq27000_write(dev, 0x56, BQ27545_CONTROL_HI);

//show control status after send key
w1_bq27000_write(dev, 0x00, BQ27545_CONTROL_LO);
w1_bq27000_write(dev, 0x00, BQ27545_CONTROL_HI);
read = bq27x00_read(di, BQ27545_CONTROL_LO, false);
pr_err("LibertyAdd: after unseal, control: 0x%x\n", read);

sample logs:
[ 14.823883, 0] LibertyAdd: before unseal, control: 0x6013
[ 15.911743, 0] LibertyAdd: after unseal, control: 0x6013 //High byte bit5 and6 should be cleared but not.

Thanks
Liberty

Hello,

If the key is 0x12345678, you will have to execute the following sequence:

key = 0x12345678
key0 = 0x1234
key1 = 0x5678

1st write to Control(): 0x78 56
2nd write to Control(): 0x34 12

So it looks like you have the keys swapped (key0/key1)

Hi Dominik,

Thanks for reply, I just workaround this issue.

I also tried the correct key send sequence before but failed.

Now my workaround is: after android OS boot up, wait 30 seconds then send unseal key to gauge, then wait 10 seconds to read control states ensure we unseal successfully. this is workable.

If I don't wait the first 30 seconds, the gauge can't be unseal.
If I don't wait the second 10 seconds, sometimes followed read operation failed.

Do you know why this happens, is there some timing rule we need follow?

Thanks
Liberty

Please see 8.5.1.2 in the datasheet for timing restrictions beyond the standard I2C electrical timing.

Your time-delays are very long and it should be possible to shorten this significantly. The gauge requires 66us and 100ms for various transactions so if you do not use any delay, a modern apps processor will likely violate these requirements. But 10 seconds and 30 seconds is excessive.

Another requirement is in 8.5.1.3, your apps processor (I2C master) must be able to handle clock stretching. The gauge will stretch SCL if it needs to wake up various internal subsystems.

About unsealing: It is very important that there is absolutely no other communication with the gauge going on when sending the unseal keys. Also, after they are sent, you should only process with data memory access if the SS bit is cleared.

Hi Dominik,

Thank you very much for reply.

We are currently using HDQ interface, if the timing restrictions for I2C also applies?

Thanks
Liberty