• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 65 subscribers
  • Views 1489 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.

EV2300: battery reflashing, reconfiguring, integration of EV2300 capabilities in environment system

Wolfgang Emmert
Prodigy 110 points

Part Number: EV2300

Hi out there,

I might have a common problem, and would like to get your kind assistance.

We have a mobile computer system with one built in rechargeable battery and additionally one battery which is replaceable. Both of them have integrated the same charge controller bq30z554.

The Charging is done via the surrounding computer system and information about current flow and gauge level are sent over the normal communication lines SMBD and SMBC.

For normal production we contact the batteries before they are built in via this interface and write all the stuff for proper funktion to the integrated controllers. Built in we now have the problem, that we cannot contact the interface wires without opening the housing of the whole system and contact the wires via soldercontacts or pins.

My thought now was whether it is possible to program or configure the batteries from the environment system (like a "recovery" or just like a firmware update). My idea was if the interface is known anyway by the system itself to get data about the gauge level showing it in Windows environment, why should it be impossible to use this interface not for a firmware update? For our service team it would be a big advantage and it would be very convenient to some service people if they could recover the firmware without an EV2300 or EV2400. Like with other recovery processes we coul keep the power supply safe and reflash the battery's firmware.

I mean, for normal production it is ok and faster, but for a service it would be a very good way and it would reduce time amount and costs. Especially for the not replaceable battery which is built in, it would be a big advantage.

  • 0
    TI__Genius 10830 points
    Hallo Wolfgang,
    Your post has been assigned to one of our BMS experts.

    Regards,
    David
  • 0
    TI__Mastermind 42535 points
    Hi Wolfgang,

    I think you are asking if we support in system upgrades for fw. Yes, you can use any i2c or smbus master. But there is a specific protocol to send the commands to the gauge to update it. This is the reason that we recommend the bqevsw and ev2400 or ev2300 for flashing as they work together to do the command translation. We do have a bqfs and dffs format which contains new fw as well as dataflash parameters. Please see link for the specified formats, training.ti.com/gauge-programming-fundamentals.
  • 0 in reply to Batt
    Prodigy 110 points
    Thank you that is the confirmation I waited for, with that we can proceed hopefully!
  • 0 in reply to Batt
    Prodigy 110 points

    Hi Batt,

    Despite my thought that the issue would have been solved, I have the message from our battery vendor that in our case the programming as you described is not possible. We have a design of the battery pack with BQ30z554 charge controller. Is that charge cobntroller able to be programmed the same way that you have described before?

    Best regards

    Wolfgang

  • 0 in reply to Wolfgang Emmert
    Intellectual 845 points

    High Wolfgang,

    The ability to in-system programming of firmware of BMS gas gauge is tampered due to the fact that gas gauge communication line is located behind Embedded Conroller, and is not directly accessible to Windows enviroment. EC is continiously talking to battery gas gauge even if Windows is in sleep mode or shut, this 'talking' is another problem with respect to 'non-removable' programming, as it may interfere any programming procedure and brick the gauge (especially if gauge is turned into 'boot rom' programming mode).
    Although these issues, some mobile PC manufacturers like Apple and Lenovo made attempts and possibilities for in-system programming of thei batteries controlers. I'am not aware about reliability of such methods, below the link to the one of such software which is limited in application only to specific mobile PCs.

    https://support.lenovo.com/gb/en/downloads/ds001322

  • 0 in reply to Igor Elremont
    Prodigy 110 points

    Hi Igor,

    thanks for this interesting link. That's the way that I want to go. Do they or somebody else have a kind of source where I could learn how to program this?

    At the moment the configure settings are flashed into the bq30z554's flash by Eval SW. If something is to be reworked I have to desolder the battery from my Windows system and put is to a programmer again. That is very unconvenient.

    If I have done all settings inside bq Evaluation SW (e.g.  V 0.9.92) I should be able to create a file. With that file which is only data, format like txt, hex, ascii, ..., I could go to some high level programming SW to shift all those information which is included to the target registers.

    Do you know whether some source code like this is available, that I could start with?

    Thanks for your ideas!

    Wolfgang

  • 0 in reply to Wolfgang Emmert
    Intellectual 845 points
    I am not aware whether such sources exists in public, most probably it's need to start from the scratch for your specific environment. It's need to look into documentation of Embedded Controller and ACPI driver (if Windows) used in your system. It should describe basic API on which system is relied on, i.e. commands set to talk with battery gas gauge. If your system could be run under Linux-based enviroment, you can look into its 'i2c-userspace' utilities and smbus kernel documentation, may be under Linux the task will be easier. And as I mentioned before the emphasis should be done 'to mute' the EC 'traffic' to gas gauge during programming phase (this functionality may be hardcoded in to EC firmware and not controllable from outside, in this case in-system programming is not safe (or even impossible) for the gas gauge, as it will need to precisely catch the 'silence window' for the programming and to have enough time to carry out eeprom configuration between EC 'talking' periods).