• State TI Thinks Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 3 answers
  • Subscribers 63 subscribers
  • Views 856 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.

Original question:

BQ28Z610: How to exit the ROM mode?

BQ28Z610: How to recover a gauge that has failed an update

Georgii Staroselskii
Prodigy 110 points
Part Number: BQ28Z610
Other Parts Discussed in Thread: BQSTUDIO

Hello, guys!

I managed to flash a bq.fs image from Linux to BQ28Z610 by using these components:

I had conducted a series of experiments w/o bumping into any issues until, well, I did. This was due to some I2C noise on the line.This led to the gauge responding on ROM mode address (0x0b).

It NAK's all reads and writes on this address, though. bqStudio also cannot help in this situation. On a Logic analyser log I see a series of NAKs from 0x16 (0x0b  << 1).

I'm wondering how can I recover the device from this state.

Sending 0x0x 0x11 to 0x0b to exit the ROM mode doesn't work as I said above. SMBUS recovery using a bq24xxx.bqz and "Advanced SMBUS communication tab" described in another post on this forum also fails.

As the device still responds on 0x0b I think that there's something left to try before admitting that this is a lost cause and soldering a new gauge.

  • 0
    TI__Mastermind 42535 points
    Hi Georgii,

    I'm actually looking into this and that's why it's taking me time to reply on PM. Expect to hear from me by tomorrow. BTW, while bqstudio will not respond on 0x16 you can still program the gauge from the firmware tab to recover it.

    I'm closing this and we can take it back on PM.
  • 0 in reply to Batt
    Prodigy 110 points

    Hello Batt,

    If bqStudio did recover it, I wouldn't write here. The Firmware tab doesn't do anything as I wrote here

    > bqStudio also cannot help in this situation. On a Logic analyser log I see a series of NAKs from 0x16 (0x0b << 1).

    This is, of course, a dump from the Firmware tab.

  • 0 in reply to Georgii Staroselskii
    TI__Mastermind 42535 points
    Can you read 0x0d and see what response you are getting? If it sends something like 0x9100 or 0x9101 then open bqstudio, go to the fw tab, uncheck execute after programming and then click on execute. If it doesn't respond with anything for the 0x0d command, then unless you have changed the address for comms in df, the IC is dead.
  • 0 in reply to Batt
    Prodigy 110 points
    As I told you above this 0x9100 thing described in another post hasn't worked out for me. The IC just NAKs everything except an i2cdetect request from Linux.

    The IC is not dead as it still responds for Linux i2cdetect and shows that there's something on the line (0x0b to be precise). I just cannot imagine that these gauges can stop functioning after an update. It doesn't really make sense for me. So I'll need a clear and definitive answer from TI that a firmware upgrade can bring the gauges into an unresponsive and unrecoverable state.
  • 0 in reply to Georgii Staroselskii
    TI__Mastermind 42535 points
    Georgii,

    Yes, an interrupted flash can have abnormal consequences. However, mostly that should leave the gauge in a programmable, recoverable state when bqstudio is used to reprogram the fw. Without any response to comms especially in flash update mode, it's difficult to debug. I've told you what we know would recover the gauge. If that doesn't work, the only thing to do is to replace it.
  • 0 in reply to Batt
    Prodigy 110 points
    Could you please point to the page in the DS that says that we can make the gauge unbootable by just a simple update failure.

    I cannot comprehend how could it happen. I just stumbled upon a second failure during an update and this is not a good sign. Could you please explain to all of us how to use this BQ28Z610 during mass production w/o bqStudio. This would help all of the users. The process that I came up with yielded some mishaps so this is not a way to go.

    I'd like to make you know one more time that the gauges that are not recoverable from bqStudio (I have two of them now) are discoverable on 0x0b address in Linux on I2C. So the bootloader code should work. i2cget/i2cset -y <N> 0x0b result in errors, though. Logic Analyzer shows that the gauge NAKs the requests.
  • 0 in reply to Georgii Staroselskii
    TI__Mastermind 42535 points
    Hi Georgii,

    This is of course not documented in the DS.

    FW and gauge execute mode are 2 different modes. I checked with the fw engineer and he mentioned that if the gauge responds in ROM mode, it should be programmable using bqstudio. One thing I can think of is if you don't have a pack side connection with sufficient tolerance (current limit) you may end up not being able to supply the gauge with enough current for erasing and writing flash. I suggest having 8V on cell and pack side with at least 100mA tolerance.

    One more thing, i2cdetect might only look for a device address response, not an actual response from the device.