• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 63 subscribers
  • Views 396 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

BQ34Z100: Error writing of golden image by microcontroller

user459307584
Prodigy 30 points
Part Number: BQ34Z100

I am developing a power control unit which permanently checks the available battery capacity of an Li-Ion battery pack. The main CPU is a LPC 4357. The BQ34Z100 is connected via I2C interface. During the production process the CPU will get a command to write the Golden Image to the BQ34Z100. The Golden Image (df-file) is part of the LPC4357 code. The original TI-Golden Image file is converted by a script to a c-file.

For writing the Golden Image the code provided in SLUA801 is taken. The adaption to the low layer drivers is implemented in the file flashStreamParserLib.c which is included in the original TI gauge.c file.

Standard access to the registers seams to be no problem, so this driver interface seams to be ok.

Writing the original TI-DF file by BQ-Studio works fine. (The BQ-Studio does not provide a trace function, so the actual behavior of the BQ-Studio is a little bit hidden) Writing the Golden Image by the LPC4357 leads to a stop after the first line written. The memory location 0x66 which always should be 0x00 indicates 0x02. This seams to be an error indication. I searched the documents for the error codes specified for memory location 0x66 but with no success.

After the BQ34Z100 indicated the error, it dies. The BQ34Z100 does no longer answer commands sent via I2C. This makes the debu

Please let me know the document where the “ERROR-REGISTER 0x66” is described. Also, all other ideas are welcome.

 

Trace output of my software:

 

flashStreamParserLib.c: processing line 13 (with 15 characters):<\r><\n>

W: 16 64 03 00<\n><\r><\n>

flashStreamParserLib.c: processing line 14 (with 6 characters):<\r><\n>

X: 20<\n><\r><\n>

flashStreamParserLib.c: processing line 15 (with 12 characters):<\r><\n>

C: 16 66 00<\n><\r><\n>

flashStreamParserLib.c: processing line 16 (with 309 characters):<\r><\n>

W: 16 00 02 00 00 00 EA FF 33 B1 FA 33 6C FB 33 95 FE 33 AD FE 33 FF FF 3F FF FF 3F FF FF 3F FF FF 3F FF FF 3F FF FF 3F FF FF 3F FF FF 3F FF FF 3F FF FF 3F FF FF 3F 16 00 3F 58 CB 33 C3 00 08 11 00 00 00 00 00 FF AA 0E FB A7 0E FF A6 0E FF A1 0E FF A0 0E FE A3 0E 61 A2 0E DE FF 3A 65 FF 3A E2 FF 33 FF AF 0E<\n><\r><\n>

flashStreamParserLib.c: processing line 17 (with 15 characters):<\r><\n>

W: 16 64 1A 37<\n><\r><\n>

flashStreamParserLib.c: processing line 18 (with 5 characters):<\r><\n>

X: 2<\n><\r><\n>

flashStreamParserLib.c: processing line 19 (with 12 characters):<\r><\n>

C: 16 66 00<\n><\r><\n>

Read:    02<\r><\n>

  ->difference in compare<\r><\n>

FAILED

 

 

 

  • 0
    Prodigy 30 points

    attachment to the inquiry:

    https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/196/BQ34Z100_5F00_Error0x02_5F00_while_5F00_writing_5F00_golden_5F00_image.7z

  • 0 in reply to user459307584
    TI__Genius 12215 points

    Hi, Jurgen

        C 16 66 00 means to read back the data from 0x66 and compares with 0, if success then move forward, otherwise report failure.

        The content of 0x66 indicates a result of previous I2C write operations, 0 indicates previous writing operation succeeded.

        If you see none zero value here, it means the programming is unsuccessful.

        Before you procced to program the data to the target device, you need to make sure the voltage read by bq34z100 is greater than the required minimum voltage. the required minimum voltage is defined in the data flash in below unit

        secondly, please make sure the I2C cable is not too long, a long cable for I2C communication can distort the data on the bus.

        If the issue still happen with above requirements are satisfied, please use a I2C monitor to collect the data when you send the I2C command to bq34z100 

  • 0 in reply to Steven Yao
    Prodigy 30 points

    I found the reason:

    I generated the Golden Image with option for DFFS file: Limit Packet Size: "No Limit" Bytes. This is not korrekt. The Limit must be set to 29 bytes. 

    There were 2. things pointing to this issue:

    1. A look to the gauge.c code:

    char *gauge_execute_fs(void *pHandle, char *pFS)
    {
    ...
    unsigned char pData[32];

    ...



    -> if the line in the Golden Image is longer than 29 bytes the array is overwritten.

    2. A I2C trace of BQ-Studio writing the golden image showed:

    golden image content: 

    line 28: 

    W: 16 00 02 00 00 00 EA FF 33 B1 FA 33 6C FB 33 95 FE 33 AD FE 33 FF FF 3F FF FF 3F FF FF 3F FF FF 3F FF FF 3F FF FF 3F FF FF 3F FF FF 3F FF FF 3F FF FF 3F FF FF 3F 16 00 3F 58 CB 33 C3 00 08 11 00 00 00 00 00 FF AA 0E FB A7 0E FF A6 0E FF A1 0E FF A0 0E FE A3 0E 61 A2 0E DE FF 3A 65 FF 3A E2 FF 33 FF AF 0E

    BQ-Studio Trace:

    "W: 16 00 02 00 00 00 EA FF 33 B1 FA 33 6C FB 33 95 FE 33 AD FE 33 FF FF 3F FF FF 3F FF FF 3F FF\n"
    "W: 16 1D FF 3F FF FF 3F FF FF 3F FF FF 3F FF FF 3F FF FF 3F FF FF 3F FF FF 3F 16 00 3F 58 CB 33\n"
    "W: 16 3A C3 00 08 11 00 00 00 00 00 FF AA 0E FB A7 0E FF A6 0E FF A1 0E FF A0 0E FE A3 0E 61 A2\n"
    "W: 16 57 0E DE FF 3A 65 FF 3A E2 FF 33 FF AF 0E\n"

    -> the BQ-Studio accepts reading the long golden image line, but it does not send the complete line to the BQ34Z100 !! It automatically splits the long line in single lines each <=29 bytes of payload

    Solution:

    Generation of golden image file with packet size limit set to 29. That's all !