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.

BQ27Z561: How to handle boards built with newer fuel gauge firmware version?

Part Number: BQ27Z561
Other Parts Discussed in Thread: BQSTUDIO

Hello,

I am currently investigating firmware programming of the BQ27Z561. I have read slua801.pdf and many posts on this forum, and some questions I have not found an answer to are the following:

Question 1: Are all BQ27Z561 IC's pre-programmed with application firmware when manufactured by TI?

Question 2: Assuming the answer to #1 is yes, what happens if production boards are built with newer BQ27Z561 firmware than what the MCU expects? Is a new golden image (battery characterization) needed?

For example, lets say we have 1000 devices with a BQ27Z561 pre-programmed with firmware version 1.00 by TI. A golden image is created in the file format df.fs and programmed to all 1000 devices at application boot as a one time occurrence by me. All 1000 devices are deployed in the field with version 1.00 and golden image data flash.

I then build 1000 more devices, but the preloaded firmware in the BQ27Z561 manufactured by TI is v1.01.

Is a new golden image needed for firmware version 1.01?

Thanks,

Derek

  • Hi Derek,

    Question 1: Yes

    Question 2: BQ27Z561 boards are compatible with all BQ27Z561 firmware so it is not necessary to create a new golden image just for that reason if you already have one. The golden image includes the firmware. Any board you load with the golden image will contain the same firmware version as the board you used to create the golden image. 

    Best,

    Jessica

  • Hey Jessica,

    Thanks for your prompt reply! A few more new questions / clarification.

    Question 1. I think I get what you are saying. Basically the BQ27Z561 can be upgraded or downgraded to any version firmware supported by that chip so long as I program the full firmware file (bq.fs). So in my example, if my golden image has firmware version 1.00 but the new BQ27Z561 IC has version 1.01, I can just program the 1.00 golden image to the chip. Is my understanding correct?

    Question 2: If possible, I want to program just the data flash portion of the image (df.fs file) since it is much smaller than the complete firmware and data flash combined file (bq.fs). However, since I cannot guarantee that new revisions of the IC will contain firmware compatible with my df.fs file, is it best practice to always program the bq.fs file to account for such circumstances?

    Thanks,

    Derek

  • Hi Derek,

    Question 1: Yes, that is correct

    Question 2: I don't think you will have any issues regarding data flash compatibility because our new firmware generally adds or enhances features in the existing firmware. The data flash addresses should also remain the same. With that said, it is always best to review the Change List before you decide which one to use.

    Best,

    Jessica

  • Hey Jessica,

    I guess to ensure that all BQ27Z561 devices perform the exact same, it is best to flash the entire golden image firmware (application + data flash) in case newer BQ27Z561 application firmware preloaded at the TI factory introduces bugs that were not present before. Such a scenario would make it difficult to pinpoint potential issues if different devices in the field were running different BQ27Z561 application firmware versions. Thanks for the clarification.

    With that being said, I plan to flash the entire firmware (application + data flash) from a MCU (Not using bqStudio). My understanding is that the bq.fs and .srec files are the same in that they program the same firmware image to flash. I am aware the bq.fs contains additional commands for wait states, checksum checking, etc. To save flash space during the BQ27Z561 programming process from our MCU, I would like to use the .srec file since it is much smaller when converted to binary (1.3 KB) than the bq.fs file (163 KB). With that in mind, I have a few more new questions:

    Question 1: Does TI provide instructions, application notes, or example code for programming a fuel gauge with the .srec or binary file from a MCU?

    The closest thing I can find is this post: https://e2e.ti.com/support/power-management-group/power-management/f/power-management-forum/889929/bq78350-r1-programming-srec-file-using-custom-tools

    Matt Sunna references a python script that he shared with another developer.

    Question 2: Is there documentation for the BQ27Z561 ROM mode commands? 

    According to the BQ27Z561 Reference Manual (SLUUC54B), 13.8.52 AltManufacturerAccess() 0x0F00 ROM Mode states the following:

    "The device goes into ROM mode to prepare for updates. The
    ROM command 0x08 returns it to FIRMWARE mode. (Note: ROM
    commands are sent to address 0x16 using the I2C protocol.)"

    The ROM commands are not documented anywhere in the reference manual and I can't find them online.

    Thanks,

    Derek

  • Hey ,

    Any update on .srec / binary programming (Question 1) and ROM mode documentation (Question 2)?

    Thanks,

    Derek

  • Hi Derek,

    1. You can create a bq.fs file and follow the Gauge Communication document.

    2. We do not document ROM mode commands for customers because ROM mode is exclusively used for programming boards. Everything you need for ROM mode is already included in the flash stream files.

    Best,

    Jessica

  • Hey Jessica,

    I'll take your last response as TI doesn't support programming with a .srec or binary file from a MCU. Using a large text file (bq.fs) is impractical for my embedded application. I'll figure something out.

    Thanks,

    Derek