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.

Updating Bq27500 / Bq27510 firmware during production - Flashstream?

Other Parts Discussed in Thread: BQ27510

During production (specifically, final testing) I'd like to have my product upgrade the firmware on the Bq27510 IC to the latest available version, and program in a matching Data Flash image. I want to do this because my supplier can't guarantee that the firmware version of supplied parts will be the latest, and I'd rather not be stuck in a situation where I have to use spring pins, test points and an EV2300 pod to upgrade the devices.

I understand this is possible, using a tool called "Flashstream". How do I go about getting a copy of this tool?

 

Thanks,

Phil.

  • Please send me a Friend request and I'll get it to you.  It's not been released publicly on ti.com yet.

    Your production programming flow would look something like this:

    Use FW_VERSION command to read current version on IC.

    If latest version, use matching dffs file to update only dataflash.

    If not latest version, use bqfs file to update dataflash and instruction flash.

  • I've sent the Friend request as you requested.

     

    Am I right in thinking that if the chip's current firmware version is newer than that of the Dataflash image, that the program procedure should be aborted?

    That is to say, can a newer firmware rev handle older Data Flash images (e.g. 1.12 firmware with 1.11 data flash), or must the two versions be matched together?

    Is there any way to tell which version of firmware a given DFI or DFFS image is intended for?

  • Definitely do NOT try to program a .DFI/.DFFS file onto an IC which has a different FW version.  If you put a golden dataflash file which was created for v1.11 on an IC with FW v1.12 on it then you will probably permanently lock up the IC and have to replace it.

    There are two ways to prevent this from happening in your flow. 

    a) use the -checkversion command-line option in Flashstream to add commands for checking the device and FW version before trying to program the flash

    b) implement the version check yourself

    Since there is no way other than the filename of your dffs file to tell what version of FW it is expecting to be programmed onto, option (a) is preferable.

  • My plan was to take the Flashstream data and transcode it into a binary format (command, length, payload) to compress it -- I don't have much Flash space available in the ATE image. It looks like I'll be adding a 16-bit WORD value to the header to store the Bq firmware version, though.

    Generally speaking, do firmware updates change the interface between the host and the gas-gauge IC? I ask because I'd rather like to avoid getting into a situation where I need to send out main-micro updates which also update the gas-gauge (unless, of course, there are serious problems). The possibility of bricking the GG IC if a firmware upgrade goes wrong makes me a bit skittish about doing GG updates outside of a factory setting (where the chip can be replaced if it becomes bricked).

    Is there any way to force the chip into ROM mode (or some kind of recovery mode) using an external stimulus, if only to fix the flash image?

    Would upgrading the firmware and/or data-flash cause the gas-gauge to lose its learned battery profiles?