• State TI Thinks Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 2 answers
  • Subscribers 62 subscribers
  • Views 1275 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.

BQ34Z100-G1: Flashing via microcontroller

Glen Cook
Prodigy 220 points
Part Number: BQ34Z100-G1
Other Parts Discussed in Thread: EV2400, BQSTUDIO

I've finished the code for flashing the fuel gauge via our microcontroller, but I find it is not very robust, i2c will often fail part way through the flashing process, or on occasions not start to flash due to the fuel gauge sending NAK's to every request.

When the fuel gauge is in the NAK mode (I'm presuming ROM mode) it cannot be flashed. However, BQ studio can flash the gauge by sending a sequence of bytes that somehow settle the fuel gauge back down into a programmable state.

I've logged this transaction as shown below


// Leave ROM mode

2.681803500000000,I2C,Setup Write to [0x16] + ACK
2.681895500000000,I2C,0x00 + ACK
2.682029500000000,I2C,0x0F + ACK
2.697807500000000,I2C,Setup Write to [0x16] + ACK
2.697900000000000,I2C,0x64 + ACK
2.698034500000000,I2C,0x0F + ACK
2.698142500000000,I2C,0x00 + ACK


5.929884000000000,I2C,Setup Write to [0xAA] + NAK
5.992867000000000,I2C,Setup Write to [0xAA] + NAK
6.009887500000000,I2C,Setup Write to [0x34] + NAK
6.070874000000000,I2C,Setup Write to [0x34] + NAK
6.085886000000000,I2C,Setup Write to [0x10] + NAK
6.148875000000000,I2C,Setup Write to [0x10] + NAK
9.258963000000000,I2C,Setup Write to [0xAA] + NAK

// Every response NAK, BQ Studio then sends the following magic sequence

W: 16 00 0D 00 00 00 00 00 00 00
W: 16 64 0D 00
C: 16 66 00
C: 16 04 01 08 00 00
C: 16 64 09 00
W: 16 00 0D
W: 16 64 0D 00
C: 16 66 00
C: 16 04 01 08

// Start of original data block which starts flashing without any problems

W: 16 00 04 00 00 00 83 DE
W: 16 64 65 01
C: 16 66 00

I've searched the forums on solutions and what this sequence actually does, but cannot find any useful information, most threads that ask questions on ROM mode appear to be locked without any answers.

Is it too much to ask to have some documentation on how to use this chip when it is in ROM mode?

The code examples that are provided (slua801) detail nothing about error recovery.

The fact you can 'brick' the chip when an error occurs, requiring the surface mounted component be replaced is beyond belief, anything brickable should have a recovery mode!

Cheers

Glen.

  • 0
    TI__Mastermind 25955 points
    Hi Glen,

    Please increase the delay between sending commands - this should resolve the NAK issue. Also, please follow this app note for information on how to program the device with a microcontroller in ROM mode:

    www.ti.com/.../slua801.pdf

    Sincerely,
    Bryan Kahler
  • 0 in reply to Bryan Kahler
    Prodigy 220 points

    Hi Bryan,

    Thanks for the response, unfortunately you didn't answer the main question. The instruction sequence sent out by battery studio is not in the bs.fs file. This sequence seems to allow the fuel gauge to recover back into a programming mode before battery studio then sends the contents of the .bs.fs file.

    What does this sequence do? I want to be able to make the micro-controller flashing the fuel gauge as robust as possible (bearing in mind problems can cause the chip to become unrecoverable, requiring major rework/cost to replace the chip) and the very limited information available on flashing isn't allowing me to do this. The code examples in slua801 do not specify what to do on an error.

    As for increasing the delay between commands, great I can do that,but how much extra delay, I've read on the forum someone said 10x the amount specified in the .bq.fs file is this the case, again lack of any decent information is very frustrating.

    What is the recovery method when one of the comparison checks fails?

    In some circumstances there are two comparison commands one after another, what is the recovery method when the 1st comparison passes and the 2nd comparison fails.

    I've already read slua801, which I did reference in my original post, but it does not have the details required.

    Cheers

    Glen.

  • 0 in reply to Bryan Kahler
    Prodigy 220 points

    See response above

  • 0 in reply to Glen Cook
    TI__Mastermind 25955 points
    Hi Glen,

    The device address changes between ROM and Firmware Modes, where it is 0x16 in ROM mode and 0xAA in Firmware mode.

    The Filestream format includes checksums and comparisons. If the comparisons are successful, you can be assured that the gauge has been programmed properly. With successful programming, the firmware may be executed and the gauge will communicate at address 0xAA.

    If a comparison fails, please retry the sequence of commands preceeding the failed comparison, starting at the command immediately after the last successful comparison.

    Alternatively, the Flash stream write process may be begun anew if the gauge fails to enter Firmware mode.

    Please make sure to have a minimum 66 us delay between every Stop and Start Condition.

    As a rule of thumb, no more than two standard commands per second, however, this is very conservative and can be broken when using a Flash Stream file that includes the required delays (the X command).

    Another training that goes more into depth with respect to the timings and filestream format may be found here:

    training.ti.com/gauge-programming-fundamentals

    The information of most interest may be at the 35 minute and later mark.

    Sincerely,
    Bryan Kahler
  • 0 in reply to Bryan Kahler
    Prodigy 220 points

    Hi Bryan,

    Thanks for the information, it was very useful.

    I'm still trying to determine why the battery studio software can recover a gauge that simply naks everything the micro-controller can throw at it.

    Is there anything special about the sequence I highlighted in the 1st post?

    Is there any documentation of the registers available in ROM mode?

    Cheers

    Glen.

  • 0 in reply to Glen Cook
    TI__Mastermind 25955 points
    Hi Glen,

    Nothing special above, just a sequence of commands to the device address in ROM mode and the address of the device when in Firmware mode. If the device is in firmware mode, it won't respond to the address in ROM mode as well as the reverse. Some users run into issues with the start/stop sequencing when using the I2C commands that are in more of a SMBUS type format. Use a logic analyzer to confirm that your commands mirror those output by bqStudio and the EV2400. The commands and timings are described in detail in the training linked above.

    There isn't any documentation of the registers in ROM mode beyond what is given in the device datasheet. ROM commands are proprietary.

    Was the discussion above helpful in bringing up the device? Is the device now working? If so, please mark as resolved so others can more easily find the issue and solution when searching the forums.

    Sincerely,
    Bryan Kahler
  • 0 in reply to Bryan Kahler
    TI__Mastermind 25955 points
    Hi Glen,

    Two weeks have passed since our last communication. Was the discussion above helpful in bringing up the device? Is the device now working? If so, please mark as resolved so others can more easily find the issue and solution when searching the forums.

    Sincerely,
    Bryan Kahler