BQ34Z100-G1: BQ34Z100-G1

Hello,

This question has been assigned and will be reviewed when possible, in the meantime please attach associated .gg/.log file.

Thank you,
Alan

Hi,

I am trying to flash a golden image (in .df.fs format) to the BQ34Z100-G1 through the i.MX8M Plus platform. I have already included the golden image file in the project build, so after flashing the full build image to the target board, I run the application generated from the pseudo code (gauge.c, gauge.h, Example Implementation of Gauge APIs for Linux® User Space I²C/dev Interface) that was provided in the gauge communication document.

However, when I check in bqStudio, it looks like the golden image is not actually programmed. For example:

• First, I changed the manufacturer name in bqStudio to ZCS and wrote it to the gauge on the target board.

• Then, I tried to flash the golden image through Linux userspace.

• After that, when I re-check in bqStudio, the manufacturer name is still the old ZCS.

This suggests that the golden image is not being successfully flashed. Is that correct, or am I missing something in the process?

Also, is there any specific sequencing I need to follow for flashing the .df.fs image?

Just to confirm, I am able to read and write to the fuel gauge registers successfully from Linux userspace.

Hi,
Could you please confirm if I should explicitly unseal the device every time I flash the golden image.

Additionally, I would appreciate your guidance on possible reasons why the golden image might not be flashing correctly, even though I am able to read and write to the fuel gauge registers from Linux userspace.

Hi,
From Linux userspace, we are able to successfully read and write fuel gauge registers (for example, control status, device type, firmware version, state of charge, voltage, etc.). However, the golden image does not appear to be programmed.

For testing, we modified the manufacturer name in bqStudio to “ZCS” and confirmed the update there. Then we tried flashing the golden image from Linux. After that, when we re-checked in bqStudio, the manufacturer name was still “ZCS,” which suggests that the golden image did not overwrite it.

Additionally, we attempted to read the manufacturer name field from Linux using the following sequence:

# Enable Data Flash access
i2cset -y 5 0x55 0x61 0x00

# Select subclass (48 → 0x30)
i2cset -y 5 0x55 0x3E 0x30

# Select block (43 → 0x2B)
i2cset -y 5 0x55 0x3F 0x2B

# Read BlockData (0x40..0x5F)

i2cdump -y 5 0x55 i 

i2cdetect -y 5 //to see the driver

//to read control register to check seal status
root@imx8mp-tesseract:/lib/firmware# i2cset -y 5 0x55 0x00 0x00 0x00 i
root@imx8mp-tesseract:/lib/firmware# i2cget -y 5 0x55 0x00 w
0x000d


//to read manufacturer name
//Enable Data Flash access (BlockDataControl = 0x00)
i2cset -y 5 0x55 0x61 0x00
//Select subclass (DataFlashClass = 48 → 0x30)
i2cset -y 5 0x55 0x3E 0x30
//Select block/offset (DataFlashBlock = 43 → 0x2B)
i2cset -y 5 0x55 0x3F 0x2B
//Read the 32-byte BlockData window (addresses 0x40..0x5F)
i2cdump -y 5 0x55 i

//result
root@imx8mp-tesseract:/lib/firmware# i2cdump -y 5 0x55 i
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: 0d 00 0c 01 91 00 08 05 34 37 33 ff 25 09 05 08    ?.???.??473.%???
10: 33 ff 00 06 ff ff ff ff ff ff ff ff ff ff ff ff    3..?............
20: 01 02 46 ff ff ff ff ff ff ff ff ff ff ff ff ff    ??F.............
30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
60: ff 00 08 06 c0 00 43 03 a0 00 27 05 48 16 44 01    ..???.C??.'?H?D?
70: 60 24 00 00 19 00 ff ff ff ff ff ff ff ff ff ff    `$..?...........
80: 0d 00 0c 01 91 00 08 05 34 37 33 ff 25 09 05 08    ?.???.??473.%???
90: 33 ff 00 06 ff ff ff ff ff ff ff ff ff ff ff ff    3..?............
a0: 01 02 46 ff ff ff ff ff ff ff ff ff ff ff ff ff    ??F.............
b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
e0: ff 00 08 06 c0 00 43 03 a0 00 27 05 48 16 44 01    ..???.C??.'?H?D?
f0: 60 24 00 00 19 00 ff ff ff ff ff ff ff ff ff ff    `$..?...........
root@imx8mp-tesseract:/lib/firmware# ^C


Manufacturer Name field is currently empty

//firmware version
root@imx8mp-tesseract:/lib/firmware# i2cset -y 5 0x55 0x00 0x02 0x00 i
root@imx8mp-tesseract:/lib/firmware# i2cget -y 5 0x55 0x00 w
0x0202


//device type
root@imx8mp-tesseract:/lib/firmware# i2cset -y 5 0x55 0x00 0x01 0x00 i
root@imx8mp-tesseract:/lib/firmware# i2cget -y 5 0x55 0x00 w
0x0100

//hardware version
root@imx8mp-tesseract:/lib/firmware# i2cset -y 5 0x55 0x00 0x03 0x00 i
root@imx8mp-tesseract:/lib/firmware# i2cget -y 5 0x55 0x00 w
0x0005

//state of charge
root@imx8mp-tesseract:/lib/firmware# i2cget -y 5 0x55 0x02 w
0x010a

//RemainingCapacity(): 0x04/0x05
root@imx8mp-tesseract:/lib/firmware# i2cget -y 5 0x55 0x04 w
0x0072

//Voltage(): 0x08/0x09 
root@imx8mp-tesseract:/lib/firmware# i2cget -y 5 0x55 0x08 w
0x3710

But the result shows the Manufacturer Name field empty, even though in bqStudio we can see the Manufacturer ID populated correctly.

So the main doubt is:

-Why does the manufacturer name appear in bqStudio but not when we try to read it directly via Linux i2cget/i2cdump commands?
 -Does this indicate an issue in how we are accessing Data Flash blocks, or is there an additional step (like checksum/unseal/commit) required before these fields can be read or written properly from Linux?
 -Also, is there a required sequence for flashing the .df.fs golden image to ensure that it takes effect other than unseal?

Hi,

We are trying to flash the golden image for the BQ34Z100-G1. While I can flash it successfully using BQStudio, We are unable to flash it from Linux userspace.

To debug, we attempted to read the manufacturer name in two ways:

1. Directly from Linux userspace using I²C commands – this works and returns the correct manufacturer name.

   # 1. Select subclass 48 (Data) : i2cset -y 5 0x55 0x3E 0x30 b

   # 2. Select block 1 (offset 32–63) : i2cset -y 5 0x55 0x3F 0x01 b

   #3 Read Full 32-Byte Block
   for i in $(seq 0x40 0x5F); do

       val=$(i2cget -y 5 0x55 $i b)

       echo -n "${val#0x} "

   done

   Echo

2. Using the C code from the TI Gauge Communication document (SLUA801), which includes gauge.c, gauge.h, and an example I²C Linux code – this does not return the correct manufacturer name.

Similarly, reading the firmware version via Linux I²C commands works:

returns 0x0202, but using the TI C example code, it does not.

Could you confirm whether the read and write functions in SLUA801 https://www.ti.com/lit/an/slua801/slua801.pdf are only compatible with the BQ27421 family and not the BQ34Z100-G1? If they are not compatible, are there any reference documents or example code for accessing configuration data and flashing the golden image for the BQ34Z100-G1 from Linux userspace?

Also earlier i had menitoned we were able to write to registers there is a correction in that we are not able to write to various registers like manufacturer name from the linux userspace

Thank you for your support.

Hi,
Referring to the document you shared, I was able to successfully change the manufacturer name from Linux userspace using I²C commands. However, since the document does not provide any pseudocode for flashing the golden image, I wanted to check the recommended approach.

Could you please clarify the following:
1.Can I reuse gauge.c and gauge.h from SLUA801( https://www.ti.com/lit/an/slua801/slua801.pdf ) as-is for BQ34Z100-G1 golden image programming, or do I need to modify/develop new drivers?

2.Is there an example specifically for BQ34Z100-G1 golden image programming available?

3.Should the golden image be written block by block, or is there a better method than sending each write command individually (which would be very time-consuming)?

[DEBUG] Line 29: Processing 'W:16643D38
X:2
C:166'
[DEBUG] Line 29: WRITE command
[DEBUG] Line 29: Parsing hex data: Address=0x16 [I2C_ADDRESS] Setting address: 0x16 (I2C: 0x0B)
Register=0x64 Data=[0x3D,0x38]
[DEBUG] Line 29: Data length: 2 bytes
[DEBUG] Line 29: Executing WRITE to register 0x64
[I2C_WRITE] Register: 0x64, Length: 2, Data: 0x3D 0x38
[I2C_WRITE] Write result: -1
[DEBUG] Line 29: Write result: -2 bytes written
[DEBUG] Line 29: Seeking next line...
[DEBUG] Line 29: Next line starts at offset 902

[DEBUG] Line 30: Processing 'X:2
C:166600
W:16000'
[DEBUG] Line 30: DELAY command
[DEBUG] Line 30: Delaying for 2 milliseconds
[DEBUG] Line 30: Delay completed
[DEBUG] Line 30: Seeking next line...
[DEBUG] Line 30: Next line starts at offset 906

[DEBUG] Line 31: Processing 'C:166600
W:160002010'
[DEBUG] Line 31: COMPARE command
[DEBUG] Line 31: Parsing hex data: Address=0x16 [I2C_ADDRESS] Setting address: 0x16 (I2C: 0x0B)
Register=0x66 Data=[0x00]
[DEBUG] Line 31: Data length: 1 bytes
[DEBUG] Line 31: Executing COMPARE on register 0x66
[I2C_READ] Register: 0x66, Length: 1
[I2C_READ] Write register result: 1
[I2C_READ] Read data result: 1
[I2C_READ] Data: 0x02
[DEBUG] Line 31: Read result: 1 bytes read
[DEBUG] Line 31: Expected: 0x00
[DEBUG] Line 31: Received: 0x02
[ERROR] Line 31: COMPARE FAILED - data mismatch!
FAILED: Flash stopped at offset 914/6748
Context around failure:
W:160002010000014F033F110CD9FF30E0FF352F100CE0FF35FFFF23E3AF04E2BF04D1FF36E2A004E3A10400C70201C602E

During the flash process, the programming executes successfully through the initial verification and unsealing stages but consistently fails when reaching the data flash block programming phase. At this point, we encounter I2C write commands returning -1, indicating communication failures, which subsequently cause compare operations to fail as the device's status register shows an error state instead of the expected success code.

Following these flash failures, the device becomes completely undetectable in bqStudio and basic I2C communication is impaired.

Additionally, we have identified a significant data flash offset discrepancy where the Manufacturer Name, which the datasheet specifies should be located at Subclass 0x30, Offset 43, is actually found at Offset 46 in practice—representing a consistent 3-byte difference that we have observed across multiple data flash parameters.
could there be an issue with this i am referring file:///D:/ZCS-Priya/002Projects/13Project_Tesseract/tes_documents/bq34z100-g1_datasheet.pdf