• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 63 subscribers
  • Views 159 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.

Original question:

Writing a gg file using the bqTools SDK

BQ40Z50: Using the bqSBB.dll for *.GG Update

Robert Andris
Intellectual 445 points
Part Number: BQ40Z50
Other Parts Discussed in Thread: BQSTUDIO, EV2400

Tool/software:

Hello,

i am again in a situation in wich i cannot update a PCB without overwriting calibration Data. Usually i use the very old bqUpdater and just set it so the Calibration Data will not be overwritten. There is some Programmers that we now use with other I2C Boards to update or Flash several different bq Chips.  I found the bqTools SDK and it actually works pretty good for me to extract a *.srec, write a GG File and to update the Chip with a new *.srec File. only Thing i am missing is the posibility to Keep the Calibration Data. For now i extract the GG File in the original State, then after i updated it. I compare both gg files and copy the Calibration Data into a new File that i still have to programm manually over the EV2300 and the BQ Studio into the Chip.

Is there a Function in the bqSBB.dll that works inverse to the WriteGGFile() that will just read a *.gg File for programming?

Thanks in Advance

Robert

  • 0
    TI__Mastermind 28450 points

    Hi Robert,

    For production purposes, we typically recommend to take the average of the produced calibration values for 20 units and load this value to the .srec, then pull it so the values are contained within the file.

    I will look into whether the .dll has the functionality that is requested.

    Regards,

    Anthony

  • 0 in reply to Anthony
    Intellectual 445 points

    Hello Anthony, 

    i was and still am super busy to find a solution to my Problem to write a gg file to the chip and i think i did not articulate my question very well when i read your answer.

    My Problem is not to find a generalized calibrationvalue to put into the *.gg file but rather to program a *.gg file into the device. The bqUSB.dll should be capable of doing this but i connot find a function similar to the "WriteGGFile() that exports a *.gg File.

    i looked into the way the Dataflash is handled and know there is an internal buffer for all the Dataflash items and i am not sure if that is the reason there is no "ReadGGFile()" Function in the bqSBB.dll. But the Desription of that dll states that this DLL is the base on wich everythin in the BQ Studio works.

    I hope this clarification helps to understand my Question

    Regards,

    Robert

  • 0 in reply to Robert Andris
    TI__Mastermind 28450 points

    Hi Robert,

    I believe we have resources on how to do this using the flashstream format for the data flash values. More information regarding this can be found in the Gauge Communication document below:

    https://www.ti.com/lit/pdf/slua801 

    Regards,

    Anthony

  • 0 in reply to Anthony
    Intellectual 445 points

    In the end, due to deadlines, I could not finish what I wanted to do and had to do some stuff manually using bqStudio.

    Maybe you can understand my request better if I explain what I have done. I have now written a CLI program (in C) that uses the EV2300/EV2400 box and the bqSBB.dll to open the correct *.bqz file provided by TI. This is my "update" process for a BMS that we cannot calibrate again because all test points are potted.

    The program:

    • Checks for the first available EVx board and connects to it.
    • Verifies the connection stability (reads some SBS data).
    • Unseals and sets Full Access mode (the BMS is already sealed).
    • Reads the data memory and writes an original.gg file.
    • Exports an original.srec file in case something goes wrong (the SREC contains calibrated and configured data of the BMS after production).
    • Flashes a new *.srec file for the new cell (so the data flash has to be programmed into the chip with the new ChemID, etc.).
    • Reads the data memory again and writes a second updated.gg file.
    • Creates a third updated_calibrated.gg file with all data from the updated.gg file, except for the lines that contain "calibration data, serial, etc." These lines are taken from the original.gg file.

    At this point, I had to manually start bqStudio, import the updated_calibrated.gg file, write it to the chip, and restart it.

    After writing, the program checks whether the calibration data is still present and correct.

    I know I can read parameters with the bqSBB.dll and could do some advanced stuff with other *.dlls provided by TI. BUT I want to stay within the framework provided by TI. So I either need a way to program the *.srec with the bqSBB.dll without overwriting the original calibration and serialized data, or I need to know how to write the *.gg file that I created to the chip. And I cannot think of a reason why this should not be possible with this *.dll.

    Your suggestion to do it with FlashStream would not help me because I cannot simply create a FlashStream file based on my update.srec without overwriting the calibration data.

    I also asked for source code in another thread for a program that might be able to do what I require, but I was denied since TI does not support the EV2400 board in production, and the EV2300 is no longer available. However, my case is not production but rather quality and service. And I am a bit surprised that we have dozens of EV2300 boards still in use but have to switch to a third-party supplier for production tools that, by the looks of it, is simply a footprint-reduced EV2300 board with a firmware lock and the functionality from TI's DLLs, along with additional "wrapper libraries" from them.

    Is there a roadmap or something outlining how TI plans to support what I consider "basic functionality" (updating a chip without overwriting calibration data) with its own chips, without relying on third-party suppliers and licenses?