BQ35100: Setting Design Capacity does not work

Hi,

The 0x3c command for design cap is a read only command. If you are attempting to write to 0x3c it will not update the value stored here. In order to write the value to 2600, you will need to write directly to the flash address 0x41fe. The procedure to write directly to this flash address can be seen as follows:

Following the steps below and substituting in the correct value (2600) and address (0x41fe) should result in the data flash value updating.

Thanks and let me know if any further questions come up,

Jackson

I am familiar with the Technical Reference Manual [www.ti.com/.../sluubh1c.pdf.

here is the first post as a list form. This is what i am experiencing.

i can write/read flash. tested with the 0x4060 for multiple bytes. and the 0x41b1 for single bytes. it works.

1. after pulling GE to low and then high, will reset the value in the flash addr: 0x41fe to 0.

2. writing 2600 into the 0x41fe address does write 2600 into the address. i can read it from there: value in the flash addr: 0x41fe is 2600.

3. reading the read only at 0x3c does not update to 2600 but stays at 2200. value in the reg addr: 0x3c  is 2200.

4. go to 1 and repeat forever

here is an excerpt from a logic analyzer that is watching the i2c line:

write to 0x55 ack data: 0x3F 0xFE 
write to 0x55 ack data: 0x40 0x0A 0x28 
write to 0x55 ack data: 0x60 0x8E 
write to 0x55 ack data: 0x0B 
read to 0x55 ack data: 0x01 0x00
write to 0x55 ack data: 0x00 0x11 0x00 
write to 0x55 ack
write to 0x55 ack data: 0x61 0x00 
write to 0x55 ack data: 0x3E 0x41 
write to 0x55 ack data: 0x3F 0xFE 
read to 0x55 ack data: 0x0A 0x28 0x00
write to 0x55 ack data: 0x3C 
read to 0x55 ack data: 0x98 0x08
write to 0x55 ack data: 0x61 0x00 
write to 0x55 ack data: 0x3E 0x41 
write to 0x55 ack data: 0x3F 0xFE 
read to 0x55 ack data: 0x0A 0x28 0x00

Reset did not change the behaviour. i waited 1000ms after reset.

Power off and on did also not help.

Also the gauge is setting itself back into SEALED mode every time the GE pin is set to low and then high. i have to set it back into UNSEALED everytime.

For some reason it is loosing its settings with every GE LOW, HIGH cycle.

Why is the gauge behaving that way? I am having lots of issues with this board and i don't see why or how it is setting back into wrong settings.

Hi,

Once the device is sealed once, it will re-enter sealed mode whenever a hard or soft reset is issued. I will take a look at the behavior where the device is resetting all settings in the lab on Monday and report back to you.

Thanks,

Jackson

interesting about the SEALED behaviour. i couldn't find the explanation for this behaviour in the technical reference. did i miss it? where would i had to look to find this explanation? Well at least i know its not some sort of brown out issue or something else. i can live with setting it into unsealed mode after every GE LOW- HIGH cycle. At least i know its intended behaviour now and not a faulty board.

ok back to the design cap:

i bought the expensive ev2400 to keep debugging it. when i set the design cap with the bq studio it sticks and stays on the correct value. But why doesn't it work from my MCU via i2c? I have to have it in production to work from my MCU and can't use the ev2400 in the field.

So i tried to get the correct i2c commands via a logic analyzer.

here are my steps:

0 connect everything and turn on bqstudio

1. turn off auto refresh as to not pollute my logger

2. click on unsealed

3. go to [Data Memory] -> [Gas Gauging]

4. turn on my i2c logic analyzer and watch the i2c lines

5. click on the value for the design capacity

6. type in the wanted number (for testing i used 3333 - > 0x0D 0x05)

7. observe the i2c lines with the logic analyzer

here is the output:

write to 0x55 ack data: 0x3E 0xE0 0x41 0x00 0x32 0x02 0x00 0x64 0x00 0x05 0x00 0x00 0x0A 0x00 0x00 0x7F 0xFF 0x0A 0xF8 0x30 0x00 0x00 0x19 0x00 0x00 0x00 0x14 0x01 0x00 0x00 0x00 0x14 0x01 
write to 0x55 ack data: 0x60 0x44 0x22 
write to 0x55 ack data: 0x3E 0xFE 0x41 0x0D 0x05 
write to 0x55 ack data: 0x60 0xAE 0x06 
write to 0x55 ack data: 0x3E 0xE0 0x41 
write to 0x55 ack data: 0x3E 
read to 0x55 ack data: 0xE0 0x41 0x00 0x32 0x02 0x00 0x64 0x00 0x05 0x00 0x00 0x0A 0x00 0x00 0x7F 0xFF 0x0A 0xF8 0x30 0x00 0x00 0x19 0x00 0x00 0x00 0x14 0x01 0x00 0x00 0x00 0x14 0x01 0x0D 0x05 0x32 0x24
write to 0x55 ack data: 0x3E 0x00 0x42 0x18 0xC0 0x0E 0x74 0x07 0xD0 0x01 0x00 0x32 0x64 0x02 0x64 
write to 0x55 ack data: 0x60 0x8F 0x10 
write to 0x55 ack data: 0x3E 0x00 0x42 
write to 0x55 ack data: 0x3E 
read to 0x55 ack data: 0x00 0x42 0x18 0xC0 0x0E 0x74 0x07 0xD0 0x01 0x00 0x32 0x64 0x02 0x64 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xA3 0x24

First of all i was surpriced by the amount of data being written onto the i2c bus. the flash addr of the design capacity is 0x41fe and the value itself only has 2 bytes. But the bqstudio is writing/reading more than hundred bytes!

I am now trying to understand what is going on here. for this i will go through the logic analyzer output line by line [line 1 to line 12].

first of all our bq35100 has the i2c address 0x55. this explains all prepending 0x55 values we write and read from.

line 1: i don't know what this line does. it doesn't even contain our new value (3333 or 0x0D 0x05). I guess it has to do with some sort of authentication? Do i even need this?

line 2: since its writing into register 0x60 i assume its the checksum of the first line.

line 3: now this line i understand. we write into the MAC register (0x3e). followed by the flash adress we want to write into (important note 0x41fe get its endian flipped and turns into 0xfe 0x41). after this we have our new value 3333 or as a hex value 0x0D 0x05. interesting enough here we dont flip endians.

line 4: this seems to be the checksum of line 3.

line 5: we are writing into the MAC register again. but why and what are we writing? assuming after the register follows a flash address again with flipped endians it would refer to the flash address: "Under Temperature Set Threshold" or 0x41e0. i don't see how this flash address would be relevant. it seems random at first. But as an integer this would be 16864. seems like its divisible by 32. (527*32=16864) maybe thats the solution to the secret? bq studio just always wants to write 32 bytes?

line 6: we just write the MAC address. that is weird. why do we do this? are we maybe trying to read the newly written content? Just to update the GUI of bqstudio and its not really needed?

line 7: i think we are reading 32 bytes. beginning at flash addr 0x41e0. here we see our friend the  0x0D 0x05 (3333) again. interesting that we read ALL bytes instead of just what the 2 bytes we need. I thought that the idea with the auto increment of the registers was used to not overload the i2c with unnecessary read/write commands but then we keep using it to do unnecessary read/write commands. 

line 8: i have no idea. we seem to write data into flash addr 0x4200. why do we do that? in these addresses are 'Cell Design Voltage' and other design parameters. but we never changed those. so why write into those flash addresses. i assume this is not needed and can be left out? am i correct in assuming this?

line 9: checksum of line 8

line 10 - line 12: we read the flash addr beyond 0x4200. i assume this is again just making sure that we actually wrote into the flash addresses and to update the bqstudio gui. even if we didn't change anything beyond 0x4200 some values in the same category of our design cap have addresses in that range.

So after hitting my head against this, here is my question:

Am i right to assume i only really need line 3 and line 4? this seems like the only lines that really do what i want it to do. Is it ok to ignore the rest? This would save a lot of i2c traffic, time and thus battery power. Especially since between line 1 and line 12 almost 1 second passes. And doing only line 3 and 4 would be done in 20 ms.