• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 63 subscribers
  • Views 1219 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-G1: QEN bit & Data Memory

Steven Ames
Prodigy 180 points
Part Number: BQ34Z100-G1
Other Parts Discussed in Thread: BQSTUDIO

Once the QEN bit has been set, is it possible to change values in the Data Memory?

I have been struggling for weeks now trying to piece together how to use this device from scattered bits of sometimes inaccurate information. For example: 7.3.3.1 Accessing Data Flash (SLUSBZ5B-JANUARY 2015-REVISED JULY 2016) on step 8 states:

“8. The new value for new_Pack_Configuration_MSB can be written by writing to the specific offset location. For example, to write 1-byte new_Pack_Configuration_MSB to Pack Configuration (offset=0) located at 0x40, use command (wr 0x4B new_Pack_Configuration_MSB)”

WHY would it work writing to 0x4B?...is this yet another diversionary TYPO?

During my many attempts at a learning session to create a Golden File, I did enable IT.

In the previously mentioned document under: 7.3.1.2.15 IT ENABLE: 0x0021 it states: “Once set, [QEN] cannot be cleared. This command is only available when the fuel gauge is UNSEALED and is typically enabled at the last step of production after the system test is completed.”

Is this similar to the I2C/HDQ one-shot only feature?...no going back? Does it physically blow a fuse that even a complete firmware update cannot return you from? Am I hosed if I enable IT before completely configuring the Data Memory?

I have carefully attempted to change the default “LION” to “NiMH” in the Data Memory with no success as of yet.

Following is a log sequence of a recent attempt:------------

Advanced Comm Transaction Log

TimeStamp , Read/Write , Address , Register , Length , Data ,

2018-07-06 02:11:08 931 , Wr , aa , 00 , 2 , 14 04

2018-07-06 02:11:22 200 , Wr , aa , 00 , 2 , 72 36

2018-07-06 02:11:37 558 , Wr , aa , 61 , 1 , 00

2018-07-06 02:12:04 684 , Wr , aa , 3e , 1 , 30

2018-07-06 02:12:18 870 , Wr , aa , 3f , 1 , 01

2018-07-06 02:12:31 390 , Rd , aa , 40 , 32 , 62 71 33 34 7A 31 30 30 2D 47 31 0B 54 65 78 61 73 20 49 6E 73 74 2E 04 4C 49 4F 4E 00 00 00 00

2018-07-06 02:13:02 605 , Rd , aa , 58 , 5 , 4C 49 4F 4E 00

2018-07-06 02:13:24 776 , Rd , aa , 60 , 1 , E3

2018-07-06 02:14:19 561 , Wr , aa , 58 , 4 , 4E 69 4D 48

2018-07-06 02:14:36 356 , Wr , aa , 60 , 1 , C9

2018-07-06 02:14:44 042 , Rd , aa , 60 , 1 , E3

2018-07-06 02:14:59 451 , Rd , aa , 40 , 32 , 62 71 33 34 7A 31 30 30 2D 47 31 0B 54 65 78 61 73 20 49 6E 73 74 2E 04 4E 69 4D 48 00 00 00 00

------------------

Following are my notes that accompany the log file:-------

Example trial: Change “LION” to “NiMH” for Device Chemistry; Subclass ID 30, block 1, offset 23, length 5

[*] = 0x6ea -> 0xea (partial CheckSum)

[62 71 33 34 7A 31 30 30 2D 47 31 0B 54 65 78 61 73 20 49 6E 73 74 2E 04] 4C 49 4F 4E 00 00 00 00 ---> E3 [old]

LION = 0x32

[62 71 33 34 7A 31 30 30 2D 47 31 0B 54 65 78 61 73 20 49 6E 73 74 2E 04] 4E 69 4D 48 00 00 00 00 ----> C9 [new?]

NiMH = 0x4c

(wr 0x00 0x14 0x04) -- 1st 2 bytes to UNSEAL

(wr 0x00 0x72 0x36) -- 2nd 2 bytes

(wr 0x61 0x00) -- BlockDataControl()

(wr 0x3e 0x30) -- DataFlashClass()

(wr 0x3f 0x01) -- block offset DataFlashBlock()

(rd 0x40 0x20) -- shows full 32 byte page

(rd 0x58 0x05) -- only the 5 bytes

(rd 0x60 0x01) -- read the CheckSum

(wr 0x58 4E 69 4D 48) -- write "NiMH"

(wr 0x60 0xC9) -- write the new CheckSum

(rd 0x60 0x01) -- read the CheckSum

(rd 0x40 0x20) -- show full 32 byte page

------

This component has already been designed into our battery fuel gauge circuit and I have been tasked with implementing the firmware. There is a fine-line between being challenged and frustrated….this project has been both.

Am I simply not calculating the CheckSum properly? The documentation suggests that when I write a correct CheckSum to 0x60 that the 32 byte buffer @ 0x40 will be written to flash. I have clearly shown the ability to change the values within the buffer, but am unable to change the CheckSum value and get things changed in Data Memory.

Any insight into how to make things work will be greatly appreciated.

Best regards,

-Steve

  • 0
    TI__Guru* 81034 points
    Hi Steve,
    I think I have an app note that may help answer some of your questions: www.ti.com/.../slua801.pdf
    I believe that the "Lion" in the data memory is a string and should not affect the behavior of the device. However, I suggest doing the full device setup in bqStudio to avoid making these difficult changes at the firmware level. bqStudio can export dataflash files in I2C or HDQ mode that you can use directly.
    Also, I just want to make sure. Have you gone through the flow to identify your ChemID and gone through the Calibration and Learning Cycle for your system? I just want to make sure you are not configuring all of the registers at the firmware level without going through these required steps to determine the critical device settings.
    Best regards,
    Matt
  • 0 in reply to Matt Sunna
    Prodigy 180 points
    Hi Matt!

    Thank you for the help.
    Knowing it was safe to change: I used “Lion” for testing if I could change *anything* in Data Memory.
    bqStudio would not change them; low-level commands would not change them.
    It appears that once that QEN bit is set...no more Data Memory changes!!!!!!
    It sort of makes sense? IF this is TRUE: it should have a significant warning next to ENABLE_IT.
    I re-flashed the device with the factory image and thankfully...the QEN bit is clear!...which means the statement about it’s a one-shot deal is NOT TRUE: to reset it: you must however Re-Flash the whole device?...is there another way for those willing to accept the risk?
    After Reflash: bqStudio can now change the Data Memory values as prescribed.
    Here’s my recommended procedure:
    Set up EVERYTHING in Data Memory first as best you can: utilizing bqStudio.
    Make sure to Write-All and Read-All on regular occasions to confirm any changes took effect.
    Once things are to your satisfaction...exit the software; power down the device; restart; verify things are how you think they should be.

    DO NOT ENABLE_IT.

    Save a memory image file...call it Pre-Golden.
    This file is your starting point if you discover during learning that you set something wrong in Data Memory.
    If you need to later change something in Data Memory: Re-Flash from your saved image; make your changes; go through learning again; save the results for the next golden image. The Golden File has QEN set and re-flashing a device will not allow you to change the Data Memory.
    If you need to change something like number of cells for the same chemistry: load up your most recent Pre-Golden and make the changes to Data Memory....save as New-Pre-Golden and go from there.

    Your mileage may vary.

    It would be nice to get confirmation from TI that this is how it works...else it’s simple observation on my part and speculation.

    I *try* to stay focused on the original question...not always successful.

    Best regards,
    -Steve
  • 0 in reply to Steven Ames
    TI__Guru* 81034 points

    Hi Steve,

    Enabling IT should not prevent the ability to change data flash. I think there must be something else causing the issue. One possibility is that the device was still sealed (unseal was not successful). The other possibility is that the "Flash Update OK Voltage" parameter is set higher than the voltage supplied (this is common with higher cell counts where the voltage is divided down).

    Best regards,

    Matt

  • 0 in reply to Matt Sunna
    Prodigy 180 points

    Hi Matt,

    *Should* not, will need some testing. After I enable IT again, I’ll give it a try. I’m pretty sure the device was reporting as unsealed, I know I sent it the UNSEAL command. Since the “Flash Update OK Voltage” is actually stored in Flash, if that value is wrong, it might be difficult to change.

    Thanks again for your help.

    Cheers,

    -Steve

  • 0 in reply to Steven Ames
    TI__Guru* 81034 points
    Thanks Steve,
    I will go ahead and close this thread. Let me know if you still see this issue next time you enable IT.
    Matt
  • 0 in reply to Matt Sunna
    Prodigy 180 points

    Matt,

    I have enabled IT and have run what appears as a successful charge/discharge learning session.

    Using bqStudio Version 1.3.86, I can easily change "Lion" to "NiMH" with no problems.

    So I would say your statement of QEN NOT preventing changes to Data Memory is _correct_!

    QEN is now set and I can still change Data Memory values.

    Not sure what was going on before, but not willing to take the time to try and replicate the condition.

    I consider the issue closed.

    Thanks your your help,

    -Steve

  • 0 in reply to Steven Ames
    TI__Guru* 81034 points
    Thanks Steve. That's great to hear!