BQ40Z50-R1: Changing Present Current Threshold through i2c/SMBus?

Hello Tahir,

There are a few threads on the forum with the default unseal keys, but if you sealed with different keys the gauge will be permanently locked if you don't have them.

Here's a thread that may be helpful for you:

https://e2e.ti.com/support/power-management-group/power-management/f/power-management-forum/664067/bq40z50-r2-unseal-the-device

Sincerely,

Wyatt Keller

Hi Wyatt,

Apologies if I was unclear in my description but I never mentioned I’m having issue with Seal/Unseal. That is working fine I verified it through “OpStatus() 0x0054”bits that device is in unsealed mode. 

I’m having issue with reading/writing the current threshold i.e 0x47DF, that what sequence needs to be sent for that. I’m able to do it through BQSTUDIO. What I see there is it’s writing 0xDF 0x47 on 0x44. And then read 0x44 to read the values. But when I do it through driver or commands it doesn’t work. Do I need to give CRC at the end as well when I’m manually doing it?

Tahir,

So DF writes could be blocked due to other reasons and your command might actually be working. The first thing to check is that your voltage is above your "valid update ok voltage". In addition DF is not writable if you have a PF triggered for any reason. So I have two questions

1) Are you able to connect to bqStudio for a quick check on the gauge status? Can you send an image of the registers screen we can review? 

2) What value are you trying to write that register to? 

Thanks,

Eric Vos

Ok so m default value is 3000mV and want to change it to 16000mv. Which I'm able to do through BQStudio but having trouble through driver. Following are register values, data memory and how I'm doing it through BQStudio.

I'm using this driver https://github.com/tibms/kernel-4.4/blob/release/drivers/power/bq40z50/bq40z50_fg.c for Linux.
I'm able to read write other MAC registers, but for Data Memory I'm stuck.

I've tried sending following combinations to bq_generic_smbus

0x44 0xDF 0x47
0x44 0x02 0xDF 0x47

0x0B 0x03 0x44 0x02 0x47

I've tried more than that for sure but just to give an idea how I'm sending commands. I've tried these by running through i2c read/write APIs which I'm 100% are correct as I'm using them to Seal/Unseal and that I've verified. But for Data Memory they are giving error as well. Do we need to add CRC at the end of this?

Tahir,

Your bqStudio looks correct and that fact that you can change it via bqStudio 100% proves it is with you communication. To debug this I suggest using a Saleae or other logic analyzer to scope both transactions and make sure they match. I will do this tomorrow or Friday to post the transaction steps and scope grabs. 

I will post an example tomorrow. 

Thanks,

Eric Vos

I did USB sniff for increasing the threshold, and this is what I'm getting there. Can you share any example of DF write? What we send first do we send size, do we send CRC at the end? And if yes how do we calculate this CRC?

Another thing which I was trying was cross compiling this program and running. write for unseal works fine, I verified unseal through BQStudio and OpStatus after unsealing it from this code. But write and bulk write both fails for DF commands. I've attached the picture of how I'm sending it for DF command.

PS: Ignore BQ27xxx in function names, haven't changed them as was trying them for testing only.

Sure. Thanks. That would be helpful in what I'm trying to do, just one more question, how are we calculating checksum here? I see there are different threads here but couldn't find any proper answer anywhere. 

Thanks. I was able to change the charger present threshold after instructions you provided. But my device is still waking up from shutdown mode even after I have increased my threshold. I've created another post for this as it is different than what I originally asked. If you could help there would really appreciate that.

e2e.ti.com/.../bq40z50-r1-charger-present-threshold-increased-but-device-still-waking-up-from-shutdown-with-voltage-less-than-threshold

@Vos @Wyatt Can you kindly reply on the link I shared above, or forward it to it's respective team. Thanks

Tahir,

I will take a look at the other link. Unfortunately prior to responding i wanted to test on an EVM. 

Thanks,

Eric Vos