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: Issues with programming monitor outside of bqStudio

Part Number: BQ34Z100


I'm working on writing firmware that has the ability to configure new BQ34Z100 battery monitors based on the Golden Image File that was generated after performing a number of optimization cycles.  I've attached that .df.fs file below.  I do not wish to update the monitor's firmware, simply the data flash that affects the configuration.

Because the commands in the .df.fs file put the monitor into ROM mode and because ROM mode commands are not adequately documented, I've run into issues that I cannot debug without outside information.

What is the nature of the "W: 16 64 <byte0> <byte1>" commands?  Additionally, when checking the status of the monitor using "C: 16 66 00", what does a return code of 0x04 indicate?

I ask, because I find that I am able to progress through the commands in the .df.fs file until I reach line 158:  "W: 16 64 63 06", as the next status check returns 0x04 instead of 0x00.  I have a feeling that these are checksum commands of some kind.  If they are, I find it interesting that the prior checksums are being accepted, but fails pretty far into the set of commands.

Thanks for the help - please let me know if any of this was unclear or if I can provide additional information.

/cfs-file/__key/communityserver-discussions-components-files/196/8547.0100_5F00_0_5F00_16_2D00_bq34z100G1.df.zip

  • Hi James,

    The ROM commands that are allowed to be disclosed are detailed in this app note: www.ti.com/.../slua801

    To ensure the DFFS output works properly, please program the golden SREC to the gauge (with the modified values) and then export the DFFS and BQFS. Please ensure that the firmware matches between the device to program and the device the DFFS was extracted from. If firmware differs, it can cause failure. In that case, please program using the BQFS.

    Sincerely,
    Bryan Kahler

  • Hi Bryan,

    Thanks for your response.  I do not believe the firmware differs as the second check of the data stream in the DFFS file is to verify the firmware version, which passes.  Your question does, however, give me concern that at some point in the future I might receive a BQ34Z100 that will have a different version of firmware, which was why I asked this question:  https://e2e.ti.com/support/power-management/f/196/t/743849.  Is it still the case that if I create a Golden Image on one BQ34Z100, that the DFFS file I pull from that chip will work on any future BQ34Z100 I receive in the future?

    After looking through the app note you linked to, including the gauge.c and gauge.h files at the end, I've found that I have relatively similar code.  I've parsed through the DFFS file and generated C code based on it.  My question is focused on understanding why, at some point after having performed what appear to be ~30 writes to the data flash, that after performing a W: 16 64 <byte0> <byte1>, the BQ34Z100 now returns a status code of 0x04 instead of 0x00. 

    I would prefer to be issuing commands to the monitor that I actually understood, so if I'm attempting to only write to the configuration data flash of the monitor (not change the firmware at all), should I be going about this a different way?  Perhaps trying to re-write the commands in the DFFS file to use the configuration update commands found in the BQ34Z100 datasheet instead of the ROM commands that are provided?

    I appreciate your help.

    James

  • Hi James,

    With respect to status code 0x04, please check to see if IT is enabled. If so, disable it in the golden master.

    Some values are only accessible in ROM and not in firmware mode. The recommended course of action for updating is using the DFFS/BQFS/SREC of a properly goldenized gauge.



    Sincerely,
    Bryan Kahler