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.

BQ20Z655-R1: Changing device parameters without BQStudio and EV2300/EV2400

Part Number: BQ20Z655-R1
Other Parts Discussed in Thread: BQSTUDIO, GPCCHEM, EV2400, , BQ40Z50, BQEVSW

Hi! I'm currently working on a project where I need to use a Battery Management System with an MCU. I am wondering if it is possible to send commands through SMBus with the MCU through to the BMS, for purposes such as changing the ChemID, setting the device to different modes, etc. Is it possible to do this without the BQStudio and the evaluation boards? 

With regards to ChemID - I will be using a Li-Ion battery to support the project. I've read in a couple of threads that these devices come pre-loaded with firmware and default settings. I've also read that ChemID is a proprietary feature locked by Texas Instruments, and thus (at least from what I have visibly seen on this forum), they are uneditable - although perhaps there are 'other' ways. I am wondering if the type of battery is the only important property of the ChemID, and if the BQ-device comes preloaded with Li-Ion as its default setting. If the situation is so that I must edit the ChemID, how should I approach this problem? 

And finally, can the BQ-device be used right away after setup and providing the necessary power supplies? 

Best, 

Riz

  • Hello Riz,

    You will need TI's tool chain in order to upload the chem ID since it contains proprietary information. You will not be able to change the chem ID using an MCU. The chem ID contains the OCV curve and temperature compensation factors. You most likely will not get good results using the default chem ID, unless you run the GPCCHEM tool and one of the close matches is the default chem ID. The GPCCHEM tool should always be used to find the chem ID.

    The gauge will need to complete a learning cycle on your actual application PCB, after the pack is learned, the gauging reported will be accurate.

    Sincerely,

    Wyatt Keller

  • Thank you for the swift reply Wyatt! The accuracy of the the gauging system is not really important, even if it gives a rough estimate. However, I am also lightly assuming that the OCV and temperature compensation factors will be used to determine cell balancing and other electrical functions of the BMS? Or is it only crucial for battery gauging purposes?

    Given that I am in a position where buying an EV2300/EV2400 is currently out of my reach, is it possible to write drivers/use the SMBUS communication protocol for anything other than ChemID through my MCU? Currently using an STM32. The PCB will be used in a student competition rocket, where sending commands to the BMS may be needed under flight, so this would be very useful. 

    Is the GPPCHEM tool part of BQStudio? 

    And how does the battery pack perform its learning cycle? I read on one of the manuals that it has a 35 minute processing time before the battery gauge can give accurate (or for my purpose, accurate enough) readings? 

    Thanks in advance! 

    Regards, 

    Riz

  • Hello Riz,

    That's correct, we rely heavily on the chem ID for relaxed gauging by referencing the the OCV table, and also for cell balancing to balance by capacity instead of voltage.

    There is no way to program the chem ID without using the TI tool chain. The idea is to have a EV2400 to program everything to the gauge and make the golden file that will be programmed into the other gauges in production.

    The GPCCHEM tool can be found here: https://www.ti.com/tool/GPCCHEM

    It is to find the bets fitting chem ID. It's not part of bqStudio, but you can use bqStudio to collect the logs needed.

    The learning cycle is a longer process than 30 min, you must read through SLUA903 to get a better understanding of what is needed.

    Sincerely,

    Wyatt Keller

  • Understood! We are unfortunately not in a position to be changing the ChemID at this point in time. This essentially removes a couple of what I understand to be important steps in the process. However, we will take this into consideration after testing - which is the phase we are currently at. It would be helpful to us if you could see the simplified workflow below and provide your insights. 

    Our intended workflow after receiving components and our PCBs (which consist of 1 MCU board and 1 BQ20Z655-R1 board) is to:

    1. Assemble the PCBs. 
      1. Our PCBs are stacked. The BQ20Z655-R1 sits on top of the MCU board through header pins. There will be no power delivery occuring between the two boards through the headers aside from logic-level signals.  
      2. Connect all peripherals/externals - this means battery and load. 
    2. Examine the BQ20Z655-R1 board and see if it works right from the box.
      1. We will plug in our power sources into the correct places on the BQ20Z655-R1 board.
      2. Seeing as we have not written a driver, I expect to see at least the LEDs lighting up. 
    3. Write a driver for the BQ-device based around the I2C/SMBus protocol that we will then use with our MCU.
      1. The main goal is simply reading off the SoC of the battery and to set sleep/wake commands through the SMBus. I assume that we do not need the BQStudio or the EV2400 to set up the drivers and send/receive data or commands.

    The questions I hope to receive answers to are as follows: 

    Is there any point in our workflow we should be worried about or one that I have made a wrong assumption of?

    Assuming that the BQ20Z655-R1 works from the get-go, as stated on step 3 is it possible to make a driver and upload it onto the MCU and instantly receive data from the BQ20Z655-R1 using default settings? 

    Does the BQ20Z655-R1 need to perform a learning cycle every time it is switched off and on?

    Could it somehow save the learning cycle in memory after first startup? 

    Best, 

    Riz

     

  • Hello Riz,

    Is this a new design? I would highly recommend not using the BQ20Z655 for new designs since we have much newer parts like the BQ40Z50 that use newer tool-chains like bqStudio and EV2400.

    I would recommend going through the TRM to get a better understanding of the part, you will need to send the IT enable in order for any gauging to start and there are a lot of protections you would need to configure to match your application.

    You can write custom drivers for the gauge, that should be no problem.

    The gauge uses flash memory, so all settings and learned values are saved in the gauge. Only one learning cycle is needed.

    Sincerely,

    Wyatt Keller

  • Thank you! This is a new design. We were going to choose the BQ40Z50, but during the design process it was out of stock at our preferred electronic suppliers. This could be a possible choice in our next design round in a couple of weeks. 

    By the TRM, do you mean the technical reference manual? And what do you mean by protections; I assume they are threshold values for, among other things, overvoltage, overtemp., undervoltage, and other protection values? Are these editable also through microcontroller or custom driver access? 

    Thanks again for your answers.

    Best, 

    Riz

  • and also, is there any documents that could provide a shorter step-by-step/practical guide on how to configure a TI battery gauge? Could I follow a tutorial made for any device in the BQ series? 

  • Hello Riz,

    I understand, the BQ20Z655 can be used, but we do not maintain the tools any longer and support is limited.

    Yes the TRM is the Technical Reference Manual. The protections are all set in the dataflash and can be modified manually with an MCU. We highly recommend using the TI tool chain for initial testing as it can save a lot of time and is used to export the final data flash image.

    Technically you only need to follow SLUA903 to get gauging results. The EVM users guide is also a good reference for initial setup. Our guides usually require the EV2300/2400 and BQEVSW/bqStudio since you need these tools in order to program the chem ID.

    Sincerely,

    Wyatt Keller 

  • Noted. I will get acquainted with the SLUA903 and the EVM manual, and will use the TRM for reference. I've found a C++/Arduino oriented code that I will work from in applying the BQ20Z655-R1 to my application, which uses an STM32. 

    Thank you for the help, Wyatt!

    Best, 

    Riz

  • Hello Riz,

    No problem, glad to help.

    Sincerely,

    Wyatt Keller